date:20150713



On 07/12/2015 11:29 PM, Matt Fischer wrote:
 We used Tempest for a time against our production environment. It was a
 pain to clean up but ephemeral test jobs solves that for you. A few
 questions: 
 
 What version of tempest will be using?

master for now. We will see if new tags are created later.
AFIK, tags mean Tempest does not support an old version of OpenStack
(ie, tempest 5 only support juno / kilo / current (liberty)).

 Will we maintain a blacklist if there are known failures? (although this
 is a pain to keep updated)

I don't think we'll have to, since tempest already provide some Python
decorators to skip some bugs. If that happens, yes we'll have to find a
way to exclude some tests or disable the run at all. That's why having
it running without affecting job return code does not break anything now.

 On Sun, Jul 12, 2015 at 8:44 PM, Emilien Macchi
 emilien.mac...@gmail.com mailto:emilien.mac...@gmail.com wrote:
 
 Hi,
 
 I would like to propose to run Tempest at the end of the beaker
 jobs, for testing purpose now.
 
 As a start, we would accept 0  1 as return code, because this is
 really experimental.
 Though I think it will be interesting to see how it behaves,
 specially when we implement new configurations or plugins in our
 modules.
 
 I already did a PoC for puppet-keystone:
 https://review.openstack.org/198561
 (failing because it needs more work to pass keystone v3 tests but v2
 tests are successful).
 As you can see the code is really light, since we use puppet-tempest.
 
 Any suggestion is welcome !
 
 -- 
 Emilien Macchi
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

-- 
Emilien Macchi



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

Re: [openstack-dev] [Fuel][Fuel-Packaging][Fuel-CI][Fuel-Infra] How to Deal with CI Failures Induced by Libraries Requirements Drift

2015-07-13 Thread Vladimir Kuklin

Oleg

The problem here is that you have this code released and it is running in
production - how are you going to fix this? Pin requirements and deal with
dependency hell?
Seriously, it is much easier to deal with explicitly frozen mirror which is
created by one 'pip install ' run than to play with implicit transitive
dependencies.

On Mon, Jul 13, 2015 at 11:58 AM, Oleg Gelbukh ogelb...@mirantis.com
wrote:

 Some comments inline.

 On Mon, Jul 13, 2015 at 9:24 AM, Bartlomiej Piotrowski 
 bpiotrow...@mirantis.com wrote:

 Freezing every moving part is complete overkill and puts a heavy burden
 on devops
 team as well as infra itself. The fix couldn't be more simple: just put
 upper
 bounds in requirements.

  1) if there is a new conflicting version, you need to set this
 upper-bound, thus you need to modify bits which get released
 It should be done as part of hard code freeze.


 As I understand, in this cases it is not code dependencies that cause
 misfunction, but dependencies of tests. This can be fixed by pinning
 test-requirements. We can do this any time, as it does not affect users.



  2) you are actually testing your code by linking it with libraries
 which are different from those that users are really using when running
 your code
 Packages dependencies should reflect these set in requirements.

  3) even if you specify an upper bound (or even fix the version) for
 this particular library, you may still fetch its newer dependency
 implicitly (by traversing indirect dependencies) with which you will be
 linking your libraries and which will actually be different from the code
 that you (and your users) use
 This can be actually said about anything, including base system Fuel is
 running. We simply do not support such setups.


 That's why we should run CI and nightly builds on stable branches. It
 catches exactly this type of issues.




  4) you may also break production installation if you fix some library
 version as it may not exist in the code bundle which gets delivered to your
 users as a set of package
 See 2.


 Again, if something in code deps breaks our stable branch, we must learn
 it as soon as possible and fix it there. However, in this case it ist the
 test requirements failure, and it should pinned in 'test-requirements.txt'
 or in requirements of our test suits.

 --
 Best regards,
 Oleg Gelbukh



 BP

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



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




-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com http://www.mirantis.ru/
www.mirantis.ru
vkuk...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master

On 2015-07-13 10:08:16 +0200 (+0200), Ihar Hrachyshka wrote:
 clients and oslo libraries still maintain their py26 for a reason:
 decision to drop py26 was for server projects only.

Yes, that decision was made at a time when our server projects had
stable branches, but our clients and shared libraries did not. My
recollection is that server projects only was a proxy for only
projects with stable branches. Now that we have stable branches of,
say, python-novaclient where we can backport juno-relevant security
fixes, people on 2.6-only platforms who want to install and run
python-novaclient from PyPI can use the stable/juno version (though
I'll admit that finding which version works with 2.6 may be a tricky
proposition for a consumer who is unaware of this situation).
-- 
Jeremy Stanley

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

Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master

2015-07-13 Thread Victor Stinner


On 13/07/2015 13:57, Jeremy Stanley wrote:

people on 2.6-only platforms who want to install and run
python-novaclient from PyPI can use the stable/juno version (though
I'll admit that finding which version works with 2.6 may be a tricky
proposition for a consumer who is unaware of this situation).


Hopefully, some Linux distro package python-novaclient and so user don't 
have to guess the version compatible with their OS.


https://packages.debian.org/jessie/python-novaclient
http://packages.ubuntu.com/fr/precise/python/python-novaclient
https://admin.fedoraproject.org/pkgdb/package/python-novaclient/
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/6/html/Command-Line_Interface_Reference_Guide/install_clients.html
etc.

Victor

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

Re: [openstack-dev] [nova] disk I/O perfomance

2015-07-13 Thread Gleb Stepanov

Hello, Warren.

Yes, we use properly filled file on a single splining drive. All tests
are done with fio, here is a link on full test report -
http://koder-ua.github.io/6.1GA/ephemeral_drive.html.
Here is a link on report for same test, executed directly on HDD, used
for ephemeral storage -
http://koder-ua.github.io/6.1GA/compute_node_HDD.html.
We are using QEMU Debian 2.0.0+dfsg-2ubuntu1.13.
Your command has following output:

virtio-blk-device.drive=drive
virtio-blk-device.logical_block_size=blocksize
virtio-blk-device.physical_block_size=blocksize
virtio-blk-device.min_io_size=uint16
virtio-blk-device.opt_io_size=uint32
virtio-blk-device.bootindex=int32
virtio-blk-device.discard_granularity=uint32
virtio-blk-device.cyls=uint32
virtio-blk-device.heads=uint32
virtio-blk-device.secs=uint32
virtio-blk-device.serial=str
virtio-blk-device.config-wce=on/off
virtio-blk-device.scsi=on/off
virtio-blk-device.x-iothread=iothread

There only one vm on this compute node, and there a lot of free resources.
Ballooning driver should not influence  performance(FUEL 6.1).

Kind regards, Gleb Stepanov.

On Fri, Jul 10, 2015 at 11:10 PM, Konstantin Danilov
kdani...@mirantis.com wrote:
 ...spinning drive based on fio.
 splining drive. All tests are done with fio, here is a link on full test
 report - http://koder-ua.github.io/6.1GA/ephemeral_drive.html.
 Here is a link on report for same test, executed directly on HDD, used for
 ephemeral storage -
 http://koder-ua.github.io/6.1GA/compute_node_HDD.html.

 We use following version of QEMU emulator version 2.0.0 (Debian
 2.0.0+dfsg-2ubuntu1.13).
 We are using QEMU Debian 2.0.0+dfsg-2ubuntu1.13.

 We have not used enviroment fully, so i guess there is not affection of
 balloning.
 There only one vm on this compute node, and there a lot of free resources.
 Ballooning driver should not influence  performance(FUEL 6.1).


 On Fri, Jul 10, 2015 at 11:00 PM, Gleb Stepanov gstepa...@mirantis.com
 wrote:

 Hello, Warren.

 Yes, we use properly filled file on a single spinning drive based on
 fio. We use following version of QEMU emulator version 2.0.0 (Debian
 2.0.0+dfsg-2ubuntu1.13).
 Your command has following output:

 virtio-blk-device.drive=drive
 virtio-blk-device.logical_block_size=blocksize
 virtio-blk-device.physical_block_size=blocksize
 virtio-blk-device.min_io_size=uint16
 virtio-blk-device.opt_io_size=uint32
 virtio-blk-device.bootindex=int32
 virtio-blk-device.discard_granularity=uint32
 virtio-blk-device.cyls=uint32
 virtio-blk-device.heads=uint32
 virtio-blk-device.secs=uint32
 virtio-blk-device.serial=str
 virtio-blk-device.config-wce=on/off
 virtio-blk-device.scsi=on/off
 virtio-blk-device.x-iothread=iothread

 We have not used enviroment fully, so i guess there is not affection
 of balloning.

 Kind regards, Gleb Stepanov.

 On Fri, Jul 10, 2015 at 6:01 PM, Gleb Stepanov gstepa...@mirantis.com
 wrote:
  -- Forwarded message --
  From: Gleb Stepanov gstepa...@mirantis.com
  Date: Wed, Jul 8, 2015 at 1:58 PM
  Subject: [nova] disk I/O perfomance
  To: openstack-operat...@lists.openstack.org,
  openstack-dev@lists.openstack.org
 
 
  Hello, all.
 
 We have measured disk I/O performance on openstack virtual machines
  with aid of
  FIO tool. We've tested performance on root dist drive device, test
  consists of write operationby 4kb
  blocks to file with size 90Gb (prefilled in advance).
  We use qcow2 image for vm, ephemeral drive and virtio driver.
  All configuration goes in attachment.
 
There are some results:
 
  test 1
 
  threads 1, 5, 10, 15, 20, 40
  iops 72,58,49,60,94,72
 
  test 2
  threads 1, 5, 10, 15, 20, 40
  iops 71,60,54,88,52,52
 
  test 3
  threads 1, 5, 10, 15, 20, 40
  iops 71,49,58,51,128,130
 
  test 4
  threads 1, 5, 10, 15, 20, 40
  iops 65,49,60,56,52,63
 
  As it is shown performance degraded during increasing amount of
  threads, also deviation of results on 40 threads is very big.
   Have you any ideas how to explain performance behaviour?
 
  Kind regards, Gleb Stepanov.




 --
 Kostiantyn Danilov aka koder.ua
 Principal software engineer, Mirantis

 skype:koder.ua
 http://koder-ua.blogspot.com/
 http://mirantis.com

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

Re: [openstack-dev] [Cinder]Restrict volume creation based on type

2015-07-13 Thread Eduard Matei

Hi,

Thanks for your replies.
Got back to the team and tried to get more input:
- the volume is created correctly (i misunderstood that part)
- the problem is that (sometimes) the instance gets spawned on the 3rd node
(which doesn't have the driver configured).
This might be because of the availability zone (volume has AZ nova,
instance has AZ nova, which refers to all 3 nodes).
I was not able to reproduce this on L, team tried with J, i will retry with
J and K and get back to you.

@Gorka: no, the hostnames are different
@Duncan: the extra-specs are volume_backend_name: swift200

Thanks,

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

Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master

2015-07-13 Thread Robert Collins

On 13 July 2015 at 20:08, Ihar Hrachyshka ihrac...@redhat.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 07/13/2015 03:29 AM, Robert Collins wrote:
 So, we've got constraints support for tox coming together nicely.

 The rollout for that will be per project (because tox.ini needs to
 change).

 However, we're not compiling, nor are we easily able to do so, a
 constraints set for Python 2.6. (We compile one unified file with
 all our constraints, which requires a VM with all the Python's we
 need to use installed on it).

 Enabling constraints on py2.6 tox jobs will fail to constrain
 anything which varies by Python version.

 So - folk that haven't disabled their 2.6 jobs (you know who you
 are) - you probably want to do so now in master. Its' my
 understanding that they were meant to be disabled during kilo but
 they've fallen through the cracks.


 clients and oslo libraries still maintain their py26 for a reason:
 decision to drop py26 was for server projects only.

Huh.

I wasn't part of that discussion... does anyone have a link to why
we're supporting a release upstream have completely moved on from 2
years ago?

Surely folk wanting to use clients from Python2.6 could just use our
older API clients, which due to good backwards compat should still
work.

-Rob


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

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

Re: [openstack-dev] [CI] How to set a proxy for zuul.

2015-07-13 Thread Tang Chen



On 07/13/2015 04:35 PM, Abhishek Shrivastava wrote:
Updating jobs using sudo jenkins-jobs --flush-cache update 
/etc/jenkins_jobs/config/. Also update the myvendor in examples.yaml




Sorry, I updated the jobs, restart the whole machine. But it still 
doesn't work.


By the way, there is no vendor in examples.yaml.

It is still this error: Project openstack-dev/sandbox not found

Anything else should I pay attention to?

Thanks.



On Mon, Jul 13, 2015 at 1:45 PM, Tang Chen tangc...@cn.fujitsu.com 
mailto:tangc...@cn.fujitsu.com wrote:



On 07/13/2015 03:50 PM, Abhishek Shrivastava wrote:

Use tester or something, also are you updating the jobs or not?


I used tester as my vendor. It doesn't work.

And what do you mean by updating the jobs ? I built the
noop-check-cimmunitication
job once in Jenkins UI. Does it matter ? All the others are not
touched.

And referring to the error, Project openstack-dev/sandbox not
found, it seems like
somewhere the project name was wrong.

right ?


Thanks.



On Mon, Jul 13, 2015 at 1:16 PM, Tang Chen
tangc...@cn.fujitsu.com mailto:tangc...@cn.fujitsu.com wrote:

Hi Abhishek,

Thanks for the quick reply.

On 07/13/2015 03:16 PM, Abhishek Shrivastava wrote:

Also check that Gearman is connecting or not through Jenkins UI.

On Mon, Jul 13, 2015 at 12:45 PM, Abhishek Shrivastava
abhis...@cloudbyte.com mailto:abhis...@cloudbyte.com wrote:

First of all, change the vendor to your vendor name in
/etc/jenkins_jobs/config/projects.yaml file. Also,
restart the zuul and zuul merger.



I did the check. Gearman plugin works find. In Jenkins UI, I
tested the connection, and it succeeded.

And also, I restarted zuul and zuul merger every time I
modified the yaml files.

But it doesn't work.

And the vendor, does that matter ?  And what vendor name
should I provide ?
I cannot find any vendor info in my Gerrit service account
profile.
For example, is XXX OK ?

Thanks.





On Mon, Jul 13, 2015 at 12:29 PM, Tang Chen
tangc...@cn.fujitsu.com
mailto:tangc...@cn.fujitsu.com wrote:

Hi all,

I have constructed my CI system.
When I tested it with sandbox project, I posted a
patch to Gerrit.

https://review.openstack.org/201002

But I got this error in zuul scheduler:

2015-07-14 14:07:24,921 DEBUG zuul.Scheduler: Run
handler awake
2015-07-14 14:07:24,921 DEBUG zuul.Scheduler:
Fetching trigger event
2015-07-14 14:07:24,922 DEBUG zuul.Scheduler:
Processing trigger event TriggerEvent comment-added
openstack-dev/sandbox master 201002,1 Verified:1
2015-07-14 14:07:24,922 DEBUG zuul.Scheduler:
Project openstack-dev/sandbox not found
2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Run
handler sleeping


My /etc/zuul/layout/layout.yaml looks like this:

projects:
  - name: openstack-dev/sandbox
check:
  - noop-check-communication


My /etc/jenkins_jobs/config/projects.yaml looks like
this:

- project:
name: sandbox
github-org: openstack-dev
node: master
vendor: myvendor

jobs:
- noop-check-communication
- dsvm-tempest-full:
node: 'devstack_slave ||
devstack-precise-check || d-p-c'


And Jenkins master works fine.


Does anyone know what is going on here ?


Thanks.






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

http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
*

*
*Thanks  Regards,
*
*Abhishek*
/_Cloudbyte Inc. http://www.cloudbyte.com_/




-- 
*

*
*Thanks  Regards,
*
*Abhishek*
/_Cloudbyte Inc. http://www.cloudbyte.com_/



__
OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [openstack][cinder]A discussion about quota update lower than current usage.

2015-07-13 Thread Duncan Thomas

The problem is, if you reject the request to lower quota unless the usage
is under the new quota, you've got an inherently racy process where the
admin needs to communicate with the tenant to say 'Stop using some of your
quota while I reduce it', which is no less complicated than 'I've reduced
your quota, now delete some resources to get under it'. It honestly sounds
like the right thing to do here is to educate the admins who are surprised
by the current behaviour, rather than to introduce a new behaviour that is
fundamentally no better.

On 13 July 2015 at 12:14, hao wang sxmatch1...@gmail.com wrote:

 Hi, Mike

 I'm not sure we really don't need any change about this feature. At least,
 some end users I faced to think there should be changed

 IMHO, there is a main problem that some users whom I faced to can't
 understand: What's the purpose that admin reduce quota lowner than existing
 usage? Limit user to can't create any resources any more? But why reduce
 quota just equal the current usage, it has same function. Make user to
 delete their resources lower than the new limit line? It's weak if user
 don't want to do that deletion and also bring some confusion to other users
 that I have mentioned.

 I understood there may be 100 reasons to show me why admin can reduce the
 quota lower than usage, and I don't want to object them too. But I hope
 this change can bring some new usage to update quota: 1. When admin use
 client(could be third party) to update the quota limit, they should check
 quota usage first as winston mentioned, if they don't or forget, anyway,
 they will change failed if quota is lower than usage, since we give the
 ability to cinder it will stop them to do that thing and make admin back to
 check quota usage. 2. If admin know what they are doing and just need to
 reduce the limit lower for some reason, fine, take the option argument
 '--force' or '--skip_validation' to update the quota.

 In personally, I felt this routine may be more improvement and little
 confusion with it. I knew Eric said that of course we can implement this
 purpose by using current APIs, it's a alternatives, but it depends on the
 application which is top on cinder I think, and is hard to have consistent.

 2015-07-11 7:24 GMT+08:00 Mike Perez thin...@gmail.com:

 On 12:30 Jul 10, hao wang wrote:
  Cinder now doesn't check the existing resource when user lower the
 quota.
  It's reasonable for admin can adjust the quota limit to lower level than
  current usage.
  But it also bring confusion that I have received to end user, they saw
 the
  current usage
  was more than limit, but they can't create resources any more.
 
  So there have been 'bug' reported[1] and code patch[2] committed, I
 knew it
  may be
  inappropriate as 'bug fix', but just want to optimize this API of
 updating
  quota.
 
  We are proposing to add an option argument which is named 'force' in
  request body.
  Of course the default value is True that means admin can adjust the
 quota
  lower then
  current usage as same as what we did now. When the force is False, that
  will occur
  a Validation and return 400 Bad Request if the update value is lower
 than
  current usage.
 
  I wonder to know folks' opinions and suggestions about this change to
 see
  if this is value to merge this patch.

 Based on the feedback received in the bug and review, it seems like there
 is
 a clear consensus that people don't want this, even if it can be bypassed
 with
 a force option.

 --
 Mike Perez

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




 --

 Best Wishes For You!


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




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

Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master

On 2015-07-13 06:03:56 -0400 (-0400), Davanum Srinivas wrote:
 Please see:
 https://etherpad.openstack.org/p/juno-cross-project-future-of-python

That decision happened at a time when there were no stable branches
of clients/libs and no expectation of their existence. Since then
the situation has changed, and it's worth revisiting that choice.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [openstack][cinder]A discussion about quota update lower than current usage.

2015-07-13 Thread hao wang

Hi, Mike

I'm not sure we really don't need any change about this feature. At least,
some end users I faced to think there should be changed

IMHO, there is a main problem that some users whom I faced to can't
understand: What's the purpose that admin reduce quota lowner than existing
usage? Limit user to can't create any resources any more? But why reduce
quota just equal the current usage, it has same function. Make user to
delete their resources lower than the new limit line? It's weak if user
don't want to do that deletion and also bring some confusion to other users
that I have mentioned.

I understood there may be 100 reasons to show me why admin can reduce the
quota lower than usage, and I don't want to object them too. But I hope
this change can bring some new usage to update quota: 1. When admin use
client(could be third party) to update the quota limit, they should check
quota usage first as winston mentioned, if they don't or forget, anyway,
they will change failed if quota is lower than usage, since we give the
ability to cinder it will stop them to do that thing and make admin back to
check quota usage. 2. If admin know what they are doing and just need to
reduce the limit lower for some reason, fine, take the option argument
'--force' or '--skip_validation' to update the quota.

In personally, I felt this routine may be more improvement and little
confusion with it. I knew Eric said that of course we can implement this
purpose by using current APIs, it's a alternatives, but it depends on the
application which is top on cinder I think, and is hard to have consistent.

2015-07-11 7:24 GMT+08:00 Mike Perez thin...@gmail.com:

 On 12:30 Jul 10, hao wang wrote:
  Cinder now doesn't check the existing resource when user lower the quota.
  It's reasonable for admin can adjust the quota limit to lower level than
  current usage.
  But it also bring confusion that I have received to end user, they saw
 the
  current usage
  was more than limit, but they can't create resources any more.
 
  So there have been 'bug' reported[1] and code patch[2] committed, I knew
 it
  may be
  inappropriate as 'bug fix', but just want to optimize this API of
 updating
  quota.
 
  We are proposing to add an option argument which is named 'force' in
  request body.
  Of course the default value is True that means admin can adjust the quota
  lower then
  current usage as same as what we did now. When the force is False, that
  will occur
  a Validation and return 400 Bad Request if the update value is lower than
  current usage.
 
  I wonder to know folks' opinions and suggestions about this change to see
  if this is value to merge this patch.

 Based on the feedback received in the bug and review, it seems like there
 is
 a clear consensus that people don't want this, even if it can be bypassed
 with
 a force option.

 --
 Mike Perez

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




-- 

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

Re: [openstack-dev] [all] Setting epoch in setup.cfg??

2015-07-13 Thread Thierry Carrez

Ian Cordasco wrote:
 On 7/10/15, 03:44, Thierry Carrez thie...@openstack.org wrote:
 Also you'll find that the various distros use different epoch values for
 the same software, because epoch are also used to cover local blunders
 in packaging and historical artifacts. That is why epochs should be
 local to each packaging system and specifying it upstream is imho
 counter-productive.
 
 So, unpopular opinion time, but I think we restrict ourselves way too much
 based on a false notion that the only people who consume OpenStack are
 consuming it via downstream packages. Joshua has pointed out a very real
 use case (deploying inside a virtual environment) and there are also cases
 where people build from source and will be (attempting) to upgrade from
 2015.1.x to 11.0.0 or 8.0.0. Even if people only use PyPI as a way of
 determining version order, using epochs will be significantly better for
 them. Perhaps I'm too late to the discussion, but it also appears no other
 opinions were solicited for it, especially not from users or operators.
 
 Specifically, I'd like to understand why using a feature of PEP 440 to
 explicitly indicate a shift in version numbering is counter-productive.
 It seems like it would be very productive for people who aren't tightly
 integrated into the development process.

By counter-productive, I meant: likely to generate more confusion than
clarity. If you provide an epoch in the version and it doesn't match
downstream packagers ones, it's hard to rely on it.

That said, I can see your point: people who consume from pip would like
to have epochs too, epoch-sanitized versioning should not be reserved to
distros.

What I want to avoid is releasing nova-2!12.0.0.0.tar.gz tarballs,
because that would be ugly (and confusing, with distros all having their
own idea of an epoch set as well). But I don't mind including an epoch=
parameter in setup.cfg if that makes pip happier.

Could you detail what your preferred system would look like ?

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [neutron] Plethora of dbase migration questions...

2015-07-13 Thread Anna Kamyshnikova

Hi, Paul!

This messages is OK. May be you can put a change on review in WIP status,
that I will be able to check what is going on? I never have such problems
with migrations in neutron-vpnaas repo. May be the problem is that database
is already upgraded, was database cleaned before you run neutron-db-manage
upgrade head?

On Tue, Jul 7, 2015 at 11:35 PM, Paul Michali p...@michali.net wrote:

 Well, I can run the upgrade command, but it doesn't seem to be processing
 my new migration file. I have tried using upgrade with 'head', and with the
 HEAD file set to the previous version and to the new version. In both
 cases, I get these info messages twice: Context impl MySWLImpl. and Will
 assume non-transactional DDL. I put a import pdb; pdb.set_trace() in my
 migration file, but it never reaches that.

 What am I possibly missing?

 Regards,

 PCM


 On Tue, Jul 7, 2015 at 4:04 PM Paul Michali p...@michali.net wrote:

 I found the issue. The upgrade is looking for config to have [database]
 section and connection definition. If I use /etc/neutron/neutron.conf, then
 the neutron-db-manage runs.



 On Tue, Jul 7, 2015 at 3:38 PM Paul Michali p...@michali.net wrote:

 I have that change in the neutron repo that is being used with by this
 neutron-vpnaas repo.

 On Tue, Jul 7, 2015 at 3:12 PM Mike Bayer mba...@redhat.com wrote:



 On 7/7/15 1:28 PM, Paul Michali wrote:

 HEAD, head, 24f28869838b (my new file) all say the same thing. :(


  On Tue, Jul 7, 2015 at 12:34 PM Salvatore Orlando sorla...@nicira.com
 wrote:

 possibly I was wrong in mixing up git  alembic.
 It should be upgrade head - lowercase.

  If that doesn't work there might some other issue lurking.

  Salvatore

 On 7 July 2015 at 17:44, Paul Michali p...@michali.net wrote:

 Salvatore,

  I changed head to the version before my new one, and then tried to
 upgrade and I see this:
   neutron-db-manage --config-file
 /opt/stack/neutron/etc/neutron.conf --service vpnaas upgrade HEAD
 Traceback (most recent call last):
   File /usr/local/bin/neutron-db-manage, line 10, in module
 sys.exit(main())
   File /opt/stack/neutron/neutron/db/migration/cli.py, line 238, in
 main
 CONF.command.func(config, CONF.command.name)
   File /opt/stack/neutron/neutron/db/migration/cli.py, line 105, in
 do_upgrade
 run_sanity_checks(config, revision)
   File /opt/stack/neutron/neutron/db/migration/cli.py, line 229, in
 run_sanity_checks
 script_dir.run_env()
   File /usr/local/lib/python2.7/dist-packages/alembic/script.py,
 line 390, in run_env
 util.load_python_file(self.dir, 'env.py')
   File /usr/local/lib/python2.7/dist-packages/alembic/util.py, line
 243, in load_python_file
 module = load_module_py(module_id, path)
   File /usr/local/lib/python2.7/dist-packages/alembic/compat.py,
 line 79, in load_module_py
 mod = imp.load_source(module_id, path, fp)
   File
 /opt/stack/neutron-vpnaas/neutron_vpnaas/db/migration/alembic_migrations/env.py,
 line 86, in module
 run_migrations_online()
   File
 /opt/stack/neutron-vpnaas/neutron_vpnaas/db/migration/alembic_migrations/env.py,
 line 67, in run_migrations_online
 engine = session.create_engine(neutron_config.database.connection)
   File
 /usr/local/lib/python2.7/dist-packages/oslo_db/sqlalchemy/engines.py,
 line 112, in create_engine
 url = sqlalchemy.engine.url.make_url(sql_connection)
   File
 /usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/url.py, line
 186, in make_url
 return _parse_rfc1738_args(name_or_url)
   File
 /usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/url.py, line
 235, in _parse_rfc1738_args
 Could not parse rfc1738 URL from string '%s' % name)
 sqlalchemy.exc.ArgumentError: Could not parse rfc1738 URL from string
 ''

  Any ideas what is wrong here?


 I'm going to guess this is the issue fixed by
 https://review.openstack.org/#/c/194197/






  On Tue, Jul 7, 2015 at 10:05 AM Paul Michali p...@michali.net wrote:


  Yes, I wasn't using the --service option, so I suspect that is why
 my down_version was wrong.  In talking with Akihiro, I added a check to
 PEP8 and made sure that it fails if head is wrong. It is:
 https://review.openstack.org/#/c/199082/
 https://review.openstack.org/#/c/199082/ (of course that failed
 py27 - I've got to see if there was some recent breakage in vpn repo,
 again).

  Regarding the migration, one of the new columns may be None, but
 there must be at least one IP version entry (there is an existing test 
 in
 VPN for using a router w/o an external IP set). Since the new code will
 rely on these new fields, I'd like to populate them as part of the
 migration. I think it would be more complicated to handle during 
 operation.

  Does anyone have examples of how to do queries of objects, from
 the migration upgrade() code?


  Regards,

  PCM

  On Tue, Jul 7, 2015 at 9:02 AM Akihiro Motoki amot...@gmail.com
 wrote:

  2015-07-07 21:39 GMT+09:00 Henry Gessau  ges...@cisco.com
 ges...@cisco.com:

  On Tue,

Re: [openstack-dev] [Murano] Versioning of Murano packages and MuranoPL classes

2015-07-13 Thread Alexander Tivelkov

Hi Gosha,

Supporting versioning in existing backend will require us to re-implement
the significant part of Artifact Repository in Murano API: we'll need to
add versions and dependencies concepts into our model (which is already
complicated and dirty enough), extend appropriate API calls etc. And all
the efforts will be a waste of time once we finally migrate to Artifacts.

Also, what do you mean by set by default? V3 API is experimental, but it
is already merged into upstream Glance, so there is no problem with using
it in Murano right away.

--
Regards,
Alexander Tivelkov

On Fri, Jul 10, 2015 at 5:56 PM, Georgy Okrokvertskhov 
gokrokvertsk...@mirantis.com wrote:

 Hi Alex,

 Thank you for the great summary.

 I have a concern about item #8. Can we add an option to Murano to use
 previous storage engine rather then Glance v3? We need to make sure that v3
 API in Glance is set by default before we do a hard dependency on it in
 Murano.

 Thanks
 Gosha

 On Fri, Jul 10, 2015 at 4:53 AM, Alexander Tivelkov 
 ativel...@mirantis.com wrote:

 Hi folks,

 Ability to manage multiple versions of application packages and their
 dependencies was always an important item in Murano roadmap, however we
 still don't have a clear spec for this feature.
 Yesterday we hosted a small design session to come up with a plan on what
 can be done in Liberty timeframe to have proper versioning for MuranoPL
 classes and packages. Stan Lagun, Kirill Zaitsev and myself participated
 offline, some other muranoers joined remotely. Thanks to everybody who
 joined us.

 TL;DR: it turns out that now we have a clear plan which will allow us to
 achieve proper versioning of the packages and classes, and we'll try to
 implement the most important parts of it in Liberty.

 Here is the detailed outcome of the session:


1. We'll use the standard Semantic Versioning format
('Major.Minor.Patch[-dev-build.label[+metadata.label]]') to version our
packages: changes which break backwards-compatibility should increment the
major segment, non-breaking new features increment the minor segment and
all non-breaking bugfixes increment the patch segment. The developers
should be carefull with the new features part: if you add a new method 
 to
a class, it may be considered a breaking change if the existing subclasses
of this class have the same method already declared. We still assume that
such changes should lead to increment of 'minor' segment, however it is up
to best judgement of developers in particular case: if the risk of such
method override is really high it may worth to increment the 'major'
segment. Proper guideline on the versioning rules will be published closer
to L release.

2. A new field 'Version' is introduced into package manifest file
which should define package version in complete semver format. The field
itself is optional (so existing apps are not broken), if it is not
specified the package is assumed to have version '0.0.0'

3. The existing 'Require' block of Application manifest will be used
to specify the package dependencies. Currently it is a yaml-based
dictionary, with the keys set to fully-qualified names of the dependency
packages and the values set to the version of those dependencies. 
 Currently
this block is used only for integration with apps stored at
apps.openstack.org. It is suggested to use this block in the
deployment process as well, and extend its semantics.
The version of the dependency specified there should also follow the
semver notation, however it may be specified in the shortened format, i.e.
without specifying the 'patch' or 'patch' and 'minior' components. In this
case the dependency will be specified as a range of allowed versions. For
example, a dependency version 1.2 will mean a (1.2.0 = version  1.3)
range.
If the version of a dependency is not specified (like in this
existing app - [1]) then we assume the version 0 - i.e. the last
available pre-release version of a package.

4. Murano core library is also a package which has its own version.
The current one is assumed to have a version 0.1.0, the one which is going
to be released in L will be probably called 0.2.0. The lib is still 
 quickly
evolving, so we are not releasing a 1.0.0 until we are sure that we are 
 not
going to have any breaking changes anytime soon.
As with any other package it will be possible to have several
versions of the Core Library installed in Murano at the same moment of 
 time.

5. There is no mandatory need to add the the dependency on the core
library to the Requires block of each application, as it is added there
implicitly. However, this implicit dependency will have a version 0 -
i.e. will reference the latest pre-release version of the Core Library
available. So it is still better to pin the core library requirement to a
particular

Re: [openstack-dev] [Fuel][Fuel-Packaging][Fuel-CI][Fuel-Infra] How to Deal with CI Failures Induced by Libraries Requirements Drift

2015-07-13 Thread Oleg Gelbukh

Vladimir,

The failures you are referring to is purely test-related failures. They
don't affect the code in production in any way, as far as I can see. All
the same, production code won't be affected by pinning versions of
test-requirements in the stable/* branches of the product and test suits.


-Oleg

On Mon, Jul 13, 2015 at 12:34 PM, Vladimir Kuklin vkuk...@mirantis.com
wrote:

 Oleg

 The problem here is that you have this code released and it is running in
 production - how are you going to fix this? Pin requirements and deal with
 dependency hell?
 Seriously, it is much easier to deal with explicitly frozen mirror which
 is created by one 'pip install ' run than to play with implicit transitive
 dependencies.

 On Mon, Jul 13, 2015 at 11:58 AM, Oleg Gelbukh ogelb...@mirantis.com
 wrote:

 Some comments inline.

 On Mon, Jul 13, 2015 at 9:24 AM, Bartlomiej Piotrowski 
 bpiotrow...@mirantis.com wrote:

 Freezing every moving part is complete overkill and puts a heavy burden
 on devops
 team as well as infra itself. The fix couldn't be more simple: just put
 upper
 bounds in requirements.

  1) if there is a new conflicting version, you need to set this
 upper-bound, thus you need to modify bits which get released
 It should be done as part of hard code freeze.


 As I understand, in this cases it is not code dependencies that cause
 misfunction, but dependencies of tests. This can be fixed by pinning
 test-requirements. We can do this any time, as it does not affect users.



  2) you are actually testing your code by linking it with libraries
 which are different from those that users are really using when running
 your code
 Packages dependencies should reflect these set in requirements.

  3) even if you specify an upper bound (or even fix the version) for
 this particular library, you may still fetch its newer dependency
 implicitly (by traversing indirect dependencies) with which you will be
 linking your libraries and which will actually be different from the code
 that you (and your users) use
 This can be actually said about anything, including base system Fuel is
 running. We simply do not support such setups.


 That's why we should run CI and nightly builds on stable branches. It
 catches exactly this type of issues.




  4) you may also break production installation if you fix some library
 version as it may not exist in the code bundle which gets delivered to your
 users as a set of package
 See 2.


 Again, if something in code deps breaks our stable branch, we must learn
 it as soon as possible and fix it there. However, in this case it ist the
 test requirements failure, and it should pinned in 'test-requirements.txt'
 or in requirements of our test suits.

 --
 Best regards,
 Oleg Gelbukh



 BP


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



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




 --
 Yours Faithfully,
 Vladimir Kuklin,
 Fuel Library Tech Lead,
 Mirantis, Inc.
 +7 (495) 640-49-04
 +7 (926) 702-39-68
 Skype kuklinvv
 35bk3, Vorontsovskaya Str.
 Moscow, Russia,
 www.mirantis.com http://www.mirantis.ru/
 www.mirantis.ru
 vkuk...@mirantis.com

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


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

Re: [openstack-dev] [Sahara] [QA] [tests coverage] Can we add CI job to control the unit tests coverage?

2015-07-13 Thread Timur Nurlygayanov

Hi,

here is the commit on review:
https://review.openstack.org/#/c/200433

We already added non-voting job in infra repository, need to merge this
script.

On Fri, Jul 3, 2015 at 1:29 PM, Anastasia Kuznetsova 
akuznets...@mirantis.com wrote:

 Boris,

 thanks for an explanation! I will take a closer look at the cover.sh
 script.

 On Fri, Jul 3, 2015 at 12:07 AM, Boris Pavlovic bpavlo...@mirantis.com
 wrote:

 Anastasia,

 because new patch may not be just a new code, committer may delete
 something or fix typos in docsting, etc.


 This job compares amount of non covered lines (before and after patch).
 If you just remove code there will be less lines that should be covered
 so amount of non covered lines will be less or the same (if everything was
 covered before)

 Fixing typos in docstrings won't introduce new lines.

 Btw job allows you to introduce  N (few) new lines that are not covered
 by unit tests that are uncovered in some cases.


 Best regards,
 Boris Pavlovic

 On Thu, Jul 2, 2015 at 10:46 AM, Anastasia Kuznetsova 
 akuznets...@mirantis.com wrote:

 Hi Timur,

 Generally I think that it is a good idea to have a gate that will check
 whether new code is covered by unit tests or not. But I am not sure that
 this gate should be voting (if I understand you correct),
 because new patch may not be just a new code, committer may delete
 something or fix typos in docsting, etc.

 On Thu, Jul 2, 2015 at 8:15 PM, Timur Nurlygayanov 
 tnurlygaya...@mirantis.com wrote:

 Hi all,

 I suggest to add CI job which will check the unit tests coverage for
 Sahara repository and will set -1 for commits with new code and without
 unit tests (if we have some degradation of tests coverage).
 This job successfully works for Rally project and it helps to organize
 the right code development process when developers write new unit tests for
 new functionality.

 we can just copy this job from Rally and start to use it for Sahara:
 Coverage control script:
 https://github.com/openstack/rally/blob/master/tests/ci/cover.sh
 Configuration file for coverage plugin (to exclude code which shouldn't
 be affected):
 https://github.com/openstack/rally/blob/master/.coveragerc
 Example of job in infra repository:
 https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L4088

 I expect that it will help to increase the tests coverage by unit tests.

 Do we have any objections?

 --

 Timur,
 Senior QA Engineer
 OpenStack Projects
 Mirantis Inc


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




 --
 Best regards,
 Anastasia Kuznetsova


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



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




 --
 Best regards,
 Anastasia Kuznetsova

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




-- 

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

Re: [openstack-dev] [Fuel][Fuel-Packaging][Fuel-CI][Fuel-Infra] How to Deal with CI Failures Induced by Libraries Requirements Drift

2015-07-13 Thread Oleg Gelbukh

Some comments inline.

On Mon, Jul 13, 2015 at 9:24 AM, Bartlomiej Piotrowski 
bpiotrow...@mirantis.com wrote:

 Freezing every moving part is complete overkill and puts a heavy burden on
 devops
 team as well as infra itself. The fix couldn't be more simple: just put
 upper
 bounds in requirements.

  1) if there is a new conflicting version, you need to set this
 upper-bound, thus you need to modify bits which get released
 It should be done as part of hard code freeze.


As I understand, in this cases it is not code dependencies that cause
misfunction, but dependencies of tests. This can be fixed by pinning
test-requirements. We can do this any time, as it does not affect users.



  2) you are actually testing your code by linking it with libraries which
 are different from those that users are really using when running your code
 Packages dependencies should reflect these set in requirements.

  3) even if you specify an upper bound (or even fix the version) for this
 particular library, you may still fetch its newer dependency implicitly (by
 traversing indirect dependencies) with which you will be linking your
 libraries and which will actually be different from the code that you (and
 your users) use
 This can be actually said about anything, including base system Fuel is
 running. We simply do not support such setups.


That's why we should run CI and nightly builds on stable branches. It
catches exactly this type of issues.




  4) you may also break production installation if you fix some library
 version as it may not exist in the code bundle which gets delivered to your
 users as a set of package
 See 2.


Again, if something in code deps breaks our stable branch, we must learn it
as soon as possible and fix it there. However, in this case it ist the test
requirements failure, and it should pinned in 'test-requirements.txt' or in
requirements of our test suits.

--
Best regards,
Oleg Gelbukh



 BP

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


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

Re: [openstack-dev] [Fuel][Fuel-Packaging][Fuel-CI][Fuel-Infra] How to Deal with CI Failures Induced by Libraries Requirements Drift

2015-07-13 Thread Vladimir Kuklin

Dima

You have a very valid point, but the is a problem here - by doing it this
way we are breaking developers' workflow which is based on using such
repositories as pypi, rubygem, etc.
If you convince developers (and I guess not only Fuel ones as we are moving
towards community engagement) to switch their workflow - I have no
objections.

Bartek

Actually, what we are doing is that we are freezing almost all the packages
(except for upstream linux maintenance updates that should not change ABIs)
thus having this drift at least constrained somehow. And this is how you
control your upper bounds - you just do not push anything new into it.


Let me provide an example why your suggestion does not work.

Imagine, we have Debian Sid repository configured for our installations (or
use some other 3rd party not strictly controlled mirror). It will work fine
until you push new oslo package which is conflicting with your stuff like
keystone, for example. And what is more important - you have already
released this keystone and you CANNOT control requirements of it, you were
not able to set them when you were working on the release because there is
actually no time machine. This means that you need either to disable this
3rd party repo or to freeze in some state or you will have the same problem
as with eggs.


On Mon, Jul 13, 2015 at 9:24 AM, Bartlomiej Piotrowski 
bpiotrow...@mirantis.com wrote:

 Freezing every moving part is complete overkill and puts a heavy burden on
 devops
 team as well as infra itself. The fix couldn't be more simple: just put
 upper
 bounds in requirements.

  1) if there is a new conflicting version, you need to set this
 upper-bound, thus you need to modify bits which get released
 It should be done as part of hard code freeze.

  2) you are actually testing your code by linking it with libraries which
 are different from those that users are really using when running your code
 Packages dependencies should reflect these set in requirements.

  3) even if you specify an upper bound (or even fix the version) for this
 particular library, you may still fetch its newer dependency implicitly (by
 traversing indirect dependencies) with which you will be linking your
 libraries and which will actually be different from the code that you (and
 your users) use
 This can be actually said about anything, including base system Fuel is
 running. We simply do not support such setups.

  4) you may also break production installation if you fix some library
 version as it may not exist in the code bundle which gets delivered to your
 users as a set of package
 See 2.

 BP

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




-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com http://www.mirantis.ru/
www.mirantis.ru
vkuk...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][lbaas] Radware unit test issues

2015-07-13 Thread Evgeny Fedoruk

Brandon, thank you.

I’ve pushed a fix for this issue https://review.openstack.org/#/c/201044

Evg

From: Brandon Logan [mailto:brandon.lo...@rackspace.com]
Sent: Friday, July 10, 2015 7:43 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][lbaas] Radware unit test issues

python's mock library had an update yesterday that exposed some issues with 
unit tests that are using the mock assert calls.  The radware tests were using 
a method called assert_called_once, which actually is not a real assert method 
off a mock.  assert_called_once_with is, though.  However, before the update 
mock would allow this method to run as it allowed any method calls to be run.  
Now with the update, only actual assert methods can be used, so that broke 
these tests.  Changing the method to something like self.assertEquals(1, 
mocked_object.call_count) failed as well because the call_count was not 
actually 1.  As such, I've pushed up a review to skip these tests.  It would be 
great if radware folks could fix these tests and unskip them as I didn't have 
the time to look into actually figuring out if the call count discrepancy is a 
real issue or not.

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

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

[openstack-dev] [neutron] Should we document the using of device:owner of the PORT ?

2015-07-13 Thread Wang, Yalei

Hi all,

The device:owner the port is defined as a 255 byte string, and is widely used 
now, indicating the use of the port.
Seems we can fill it freely, and user also could update/set it from cmd 
line(port-update $PORT_ID --device_owner), and I don't find the guideline for 
using.

What is its function? For indicating the using of the port, and seems horizon 
also use it to show the topology.
And nova really need it editable, should we at least document all of the 
possible values into some guide to make it clear? If yes, I can do it.


I got these using from the code(maybe not complete, pls point it out):

From constants.py,
DEVICE_OWNER_ROUTER_HA_INTF = network:router_ha_interface
DEVICE_OWNER_ROUTER_INTF = network:router_interface
DEVICE_OWNER_ROUTER_GW = network:router_gateway
DEVICE_OWNER_FLOATINGIP = network:floatingip
DEVICE_OWNER_DHCP = network:dhcp
DEVICE_OWNER_DVR_INTERFACE = network:router_interface_distributed
DEVICE_OWNER_AGENT_GW = network:floatingip_agent_gateway
DEVICE_OWNER_ROUTER_SNAT = network:router_centralized_snat
DEVICE_OWNER_LOADBALANCER = neutron:LOADBALANCER

And from debug_agent.py
DEVICE_OWNER_NETWORK_PROBE = 'network:probe'
DEVICE_OWNER_COMPUTE_PROBE = 'compute:probe'

And setting from nova/network/neutronv2/api.py,
'compute:%s' % instance.availability_zone


Thanks all!

/Yalei

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

[openstack-dev] [trove]Expose new API for monitoring

2015-07-13 Thread 陈迪豪

We have proposing the blueprint about exposing new API for monitoring in 
https://blueprints.launchpad.net/trove/+spec/expose-new-api-for-monitoring


Looking forward to any discussion :)


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

Re: [openstack-dev] [neutron] Reading an updated port's fixed IPs in mech driver update_port_postcommit

2015-07-13 Thread Rossella Sblendido

Hi Neil

On 07/10/2015 12:49 PM, Neil Jerram wrote:
 A pragmatic fix appears to be to explicitly requery the IPAllocation
 table, as you can see in the two commits here:
 https://github.com/Metaswitch/calico/commit/5512ce7dd50db414f161bddcef17b0846a1466ac
 
 https://github.com/Metaswitch/calico/commit/4ecaf3568af52ef9cc29662a3b94672540056f05
 

in the second commit you actually set the right context, using context
instead of context._plugin_context. Why didn't you replace
context._plugin_context everywhere in that file, I think that might fix
the issue.

cheers,

Rossella

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

[openstack-dev] [magnum] The way magnum-conductor communicates with k8s master

2015-07-13 Thread 王华

Hi, all.

  Currently magnum-conductor can communicates with k8s master which has a
floating ip in all-in-one deployment. But if magnum-conductor is not
deployed on the neutron network node which has the br-ex, how can
magnum-conductor communicate with k8s master. The magnum-conductor node
then has no access to the k8s master.

  Another question:
  Magnum-conductor only communicate with k8s master, why k8s minion has a
floating ip too? What is the floating ip of k8s minion used for?

Looking forward to any discussion.

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

Re: [openstack-dev] [CI] How to set a proxy for zuul.

2015-07-13 Thread Abhishek Shrivastava

Instead of it use reusable_node option.

On Tue, Jul 14, 2015 at 9:12 AM, Tang Chen tangc...@cn.fujitsu.com wrote:

  Hi Abhishek, All,

 I found the problem.

 My /etc/zuul/layout/layout.yaml has the following config:

 jobs:
   - name: ^dsvm-tempest.*$
 parameter-function: single_use_node

 But in _parseConfig() in zuul/scheduler.py, it failed to find
 single_use_node().

 fname = config_job.get('parameter-function', None)
 if fname:
 func = config_env.get(fname, None)
 if not func:
 raise Exception(Unable to find function %s % fname)

 So projects section was not parsed.

 Does anyone know why ?

 Thanks.




 On 07/14/2015 10:54 AM, Tang Chen wrote:

 Hi Abhishek,

 I printed the self.layout.projects in zuul/scheduler.py, it is empty.
 So the project was not found.

 But I did do the jenkins-jobs --flush-cache update
 /etc/jenkins_jobs/config/
 And I did configure openstack-dev/sandbox in layout.yaml.

 Do you have any idea what's wrong here ?

 Thanks.


 On 07/13/2015 05:58 PM, Tang Chen wrote:


 On 07/13/2015 04:35 PM, Abhishek Shrivastava wrote:

  Updating jobs using sudo jenkins-jobs --flush-cache update
 /etc/jenkins_jobs/config/. Also update the myvendor in examples.yaml


 Sorry, I updated the jobs, restart the whole machine. But it still doesn't
 work.

 By the way, there is no vendor in examples.yaml.

 It is still this error: Project openstack-dev/sandbox not found

 Anything else should I pay attention to?

 Thanks.


 On Mon, Jul 13, 2015 at 1:45 PM, Tang Chen tangc...@cn.fujitsu.com
 wrote:


 On 07/13/2015 03:50 PM, Abhishek Shrivastava wrote:

   Use tester or something, also are you updating the jobs or not?


  I used tester as my vendor. It doesn't work.

 And what do you mean by updating the jobs ? I built the
 noop-check-cimmunitication
 job once in Jenkins UI. Does it matter ? All the others are not touched.

 And referring to the error, Project openstack-dev/sandbox not found, it
 seems like
 somewhere the project name was wrong.

 right ?


 Thanks.


 On Mon, Jul 13, 2015 at 1:16 PM, Tang Chen tangc...@cn.fujitsu.com
 wrote:

  Hi Abhishek,

 Thanks for the quick reply.

 On 07/13/2015 03:16 PM, Abhishek Shrivastava wrote:

  Also check that Gearman is connecting or not through Jenkins UI.

 On Mon, Jul 13, 2015 at 12:45 PM, Abhishek Shrivastava 
 abhis...@cloudbyte.com wrote:

  First of all, change the vendor to your vendor name in
 /etc/jenkins_jobs/config/projects.yaml file. Also, restart the zuul
 and zuul merger.


  I did the check. Gearman plugin works find. In Jenkins UI, I tested the
 connection, and it succeeded.

 And also, I restarted zuul and zuul merger every time I modified the
 yaml files.

 But it doesn't work.

 And the vendor, does that matter ?  And what vendor name should I
 provide ?
 I cannot find any vendor info in my Gerrit service account profile.
 For example, is XXX OK ?

 Thanks.




 On Mon, Jul 13, 2015 at 12:29 PM, Tang Chen tangc...@cn.fujitsu.com
 wrote:

 Hi all,

 I have constructed my CI system.
 When I tested it with sandbox project, I posted a patch to Gerrit.

 https://review.openstack.org/201002

 But I got this error in zuul scheduler:

 2015-07-14 14:07:24,921 DEBUG zuul.Scheduler: Run handler awake
 2015-07-14 14:07:24,921 DEBUG zuul.Scheduler: Fetching trigger event
 2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Processing trigger event
 TriggerEvent comment-added openstack-dev/sandbox master 201002,1
 Verified:1
 2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Project
 openstack-dev/sandbox not found
 2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Run handler sleeping


 My /etc/zuul/layout/layout.yaml looks like this:

 projects:
   - name: openstack-dev/sandbox
 check:
   - noop-check-communication


 My /etc/jenkins_jobs/config/projects.yaml looks like this:

 - project:
 name: sandbox
 github-org: openstack-dev
 node: master
 vendor: myvendor

 jobs:
 - noop-check-communication
 - dsvm-tempest-full:
 node: 'devstack_slave || devstack-precise-check || d-p-c'


 And Jenkins master works fine.


 Does anyone know what is going on here ?


 Thanks.






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




   --


 *Thanks  Regards, *
 *Abhishek*
  *Cloudbyte Inc. http://www.cloudbyte.com*




  --


 *Thanks  Regards, *
 *Abhishek*
  *Cloudbyte Inc. http://www.cloudbyte.com*


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

Re: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

2015-07-13 Thread Sam Yaple

+1 from me.

Paul reviews are always helpful and easily in the same number with the
other Core members (108 reviews this cycle!). Additionally he has been
helpful in testing the new Ansible pieces as well as pushing forward the
source installation, both areas we need help in currently.

Sam Yaple

On Mon, Jul 13, 2015 at 9:40 PM, Steven Dake (stdake) std...@cisco.com
wrote:

  Hey folks,

  I am proposing Paul Bourke for the Kolla core team.  He did a fantastic
 job getting Kolla into shape to support multiple distros and from
 source/from binary installation.  His statistics are fantastic including
 both code and reviews.  His reviews are not only voluminous, but
 consistently good.  Paul is helping on many fronts and I would feel make a
 fantastic addition to our core reviewer team.

  Consider my proposal to count as one +1 vote.

  Any Kolla core is free to vote +1, abstain, or vote –1.  A –1 vote is a
 veto for the candidate, so if you are on the fence, best to abstain :)  We
 require 3 core reviewer votes to approve a candidate.  I will leave the
 voting open until July 20th  UTC.  If the vote is unanimous prior to
 that time or a veto vote is received, I’ll close voting and make
 appropriate adjustments to the gerrit groups.

  Regards
 -steve

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


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

[openstack-dev] version cap on libs

2015-07-13 Thread Takashi Yamamoto

hi,

what's the status of patches like this?
https://review.openstack.org/#/c/173834/

we still haven't decided how to handle that?

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

[openstack-dev] How to use security-port in kilo?

2015-07-13 Thread 16189...@qq.com

Hi all,
Recently I want to have a try of the  feature security-port, but these is 
very few introduction. Could you give some help?
Thank you.


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

Re: [openstack-dev] [CI] How to set a proxy for zuul.

2015-07-13 Thread Tang Chen


Hi Abhishek,

I printed the self.layout.projects in zuul/scheduler.py, it is empty.
So the project was not found.

But I did do the jenkins-jobs --flush-cache update /etc/jenkins_jobs/config/
And I did configure openstack-dev/sandbox in layout.yaml.

Do you have any idea what's wrong here ?

Thanks.


On 07/13/2015 05:58 PM, Tang Chen wrote:


On 07/13/2015 04:35 PM, Abhishek Shrivastava wrote:
Updating jobs using sudo jenkins-jobs --flush-cache update 
/etc/jenkins_jobs/config/. Also update the myvendor in examples.yaml




Sorry, I updated the jobs, restart the whole machine. But it still 
doesn't work.


By the way, there is no vendor in examples.yaml.

It is still this error: Project openstack-dev/sandbox not found

Anything else should I pay attention to?

Thanks.



On Mon, Jul 13, 2015 at 1:45 PM, Tang Chen tangc...@cn.fujitsu.com 
mailto:tangc...@cn.fujitsu.com wrote:



On 07/13/2015 03:50 PM, Abhishek Shrivastava wrote:

Use tester or something, also are you updating the jobs or not?


I used tester as my vendor. It doesn't work.

And what do you mean by updating the jobs ? I built the
noop-check-cimmunitication
job once in Jenkins UI. Does it matter ? All the others are not
touched.

And referring to the error, Project openstack-dev/sandbox not
found, it seems like
somewhere the project name was wrong.

right ?


Thanks.



On Mon, Jul 13, 2015 at 1:16 PM, Tang Chen
tangc...@cn.fujitsu.com mailto:tangc...@cn.fujitsu.com wrote:

Hi Abhishek,

Thanks for the quick reply.

On 07/13/2015 03:16 PM, Abhishek Shrivastava wrote:

Also check that Gearman is connecting or not through
Jenkins UI.

On Mon, Jul 13, 2015 at 12:45 PM, Abhishek Shrivastava
abhis...@cloudbyte.com mailto:abhis...@cloudbyte.com wrote:

First of all, change the vendor to your vendor name
in /etc/jenkins_jobs/config/projects.yaml file. Also,
restart the zuul and zuul merger.



I did the check. Gearman plugin works find. In Jenkins UI, I
tested the connection, and it succeeded.

And also, I restarted zuul and zuul merger every time I
modified the yaml files.

But it doesn't work.

And the vendor, does that matter ?  And what vendor name
should I provide ?
I cannot find any vendor info in my Gerrit service account
profile.
For example, is XXX OK ?

Thanks.





On Mon, Jul 13, 2015 at 12:29 PM, Tang Chen
tangc...@cn.fujitsu.com
mailto:tangc...@cn.fujitsu.com wrote:

Hi all,

I have constructed my CI system.
When I tested it with sandbox project, I posted a
patch to Gerrit.

https://review.openstack.org/201002

But I got this error in zuul scheduler:

2015-07-14 14:07:24,921 DEBUG zuul.Scheduler: Run
handler awake
2015-07-14 14:07:24,921 DEBUG zuul.Scheduler:
Fetching trigger event
2015-07-14 14:07:24,922 DEBUG zuul.Scheduler:
Processing trigger event TriggerEvent
comment-added openstack-dev/sandbox master 201002,1
Verified:1
2015-07-14 14:07:24,922 DEBUG zuul.Scheduler:
Project openstack-dev/sandbox not found
2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Run
handler sleeping


My /etc/zuul/layout/layout.yaml looks like this:

projects:
  - name: openstack-dev/sandbox
check:
  - noop-check-communication


My /etc/jenkins_jobs/config/projects.yaml looks
like this:

- project:
name: sandbox
github-org: openstack-dev
node: master
vendor: myvendor

jobs:
- noop-check-communication
- dsvm-tempest-full:
node: 'devstack_slave ||
devstack-precise-check || d-p-c'


And Jenkins master works fine.


Does anyone know what is going on here ?


Thanks.






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

http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
*

*
*Thanks  Regards,
*
*Abhishek*

Re: [openstack-dev] [magnum] The way magnum-conductor communicates with k8s master

2015-07-13 Thread OTSUKA , Motohiro

Hi, Wanghua
 
   Currently magnum-conductor can communicates with k8s master which has a 
 floating ip in all-in-one deployment. But if magnum-conductor is not deployed 
 on the neutron network node which has the br-ex, how can magnum-conductor 
 communicate with k8s master. The magnum-conductor node then has no access to 
 the k8s master.
Currently this is a limitation of our architecture.
 
 
   Another question:
   Magnum-conductor only communicate with k8s master, why k8s minion has a 
 floating ip too? What is the floating ip of k8s minion used for?
 
I think, there is no reason.
Historically, Our heat template come from larsks/heat-kubernetes [1] template.
larsks/heat-kubernetes provides floating ip to minion nodes, this is just a 
reason.


[1]: https://github.com/larsks/heat-kubernetes 

Thanks
-Yuanying


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

Re: [openstack-dev] [CI] How to set a proxy for zuul.

2015-07-13 Thread Tang Chen


Hi Abhishek, All,

I found the problem.

My /etc/zuul/layout/layout.yaml has the following config:

jobs:
  - name: ^dsvm-tempest.*$
parameter-function: single_use_node

But in _parseConfig() in zuul/scheduler.py, it failed to find 
single_use_node().


fname = config_job.get('parameter-function', None)
if fname:
func = config_env.get(fname, None)
if not func:
raise Exception(Unable to find function %s % fname)

So projects section was not parsed.

Does anyone know why ?

Thanks.



On 07/14/2015 10:54 AM, Tang Chen wrote:

Hi Abhishek,

I printed the self.layout.projects in zuul/scheduler.py, it is empty.
So the project was not found.

But I did do the jenkins-jobs --flush-cache update 
/etc/jenkins_jobs/config/

And I did configure openstack-dev/sandbox in layout.yaml.

Do you have any idea what's wrong here ?

Thanks.


On 07/13/2015 05:58 PM, Tang Chen wrote:


On 07/13/2015 04:35 PM, Abhishek Shrivastava wrote:
Updating jobs using sudo jenkins-jobs --flush-cache update 
/etc/jenkins_jobs/config/. Also update the myvendor in examples.yaml




Sorry, I updated the jobs, restart the whole machine. But it still 
doesn't work.


By the way, there is no vendor in examples.yaml.

It is still this error: Project openstack-dev/sandbox not found

Anything else should I pay attention to?

Thanks.



On Mon, Jul 13, 2015 at 1:45 PM, Tang Chen tangc...@cn.fujitsu.com 
mailto:tangc...@cn.fujitsu.com wrote:



On 07/13/2015 03:50 PM, Abhishek Shrivastava wrote:

Use tester or something, also are you updating the jobs or not?


I used tester as my vendor. It doesn't work.

And what do you mean by updating the jobs ? I built the
noop-check-cimmunitication
job once in Jenkins UI. Does it matter ? All the others are not
touched.

And referring to the error, Project openstack-dev/sandbox not
found, it seems like
somewhere the project name was wrong.

right ?


Thanks.



On Mon, Jul 13, 2015 at 1:16 PM, Tang Chen
tangc...@cn.fujitsu.com mailto:tangc...@cn.fujitsu.com wrote:

Hi Abhishek,

Thanks for the quick reply.

On 07/13/2015 03:16 PM, Abhishek Shrivastava wrote:

Also check that Gearman is connecting or not through
Jenkins UI.

On Mon, Jul 13, 2015 at 12:45 PM, Abhishek Shrivastava
abhis...@cloudbyte.com mailto:abhis...@cloudbyte.com
wrote:

First of all, change the vendor to your vendor name
in /etc/jenkins_jobs/config/projects.yaml file. Also,
restart the zuul and zuul merger.



I did the check. Gearman plugin works find. In Jenkins UI,
I tested the connection, and it succeeded.

And also, I restarted zuul and zuul merger every time I
modified the yaml files.

But it doesn't work.

And the vendor, does that matter ?  And what vendor name
should I provide ?
I cannot find any vendor info in my Gerrit service account
profile.
For example, is XXX OK ?

Thanks.





On Mon, Jul 13, 2015 at 12:29 PM, Tang Chen
tangc...@cn.fujitsu.com
mailto:tangc...@cn.fujitsu.com wrote:

Hi all,

I have constructed my CI system.
When I tested it with sandbox project, I posted a
patch to Gerrit.

https://review.openstack.org/201002

But I got this error in zuul scheduler:

2015-07-14 14:07:24,921 DEBUG zuul.Scheduler: Run
handler awake
2015-07-14 14:07:24,921 DEBUG zuul.Scheduler:
Fetching trigger event
2015-07-14 14:07:24,922 DEBUG zuul.Scheduler:
Processing trigger event TriggerEvent
comment-added openstack-dev/sandbox master
201002,1 Verified:1
2015-07-14 14:07:24,922 DEBUG zuul.Scheduler:
Project openstack-dev/sandbox not found
2015-07-14 14:07:24,922 DEBUG zuul.Scheduler: Run
handler sleeping


My /etc/zuul/layout/layout.yaml looks like this:

projects:
  - name: openstack-dev/sandbox
check:
  - noop-check-communication


My /etc/jenkins_jobs/config/projects.yaml looks
like this:

- project:
name: sandbox
github-org: openstack-dev
node: master
vendor: myvendor

jobs:
- noop-check-communication
- dsvm-tempest-full:
node: 'devstack_slave || devstack-precise-check ||
d-p-c'


And Jenkins master works fine.


Does anyone know what is going on here ?

Re: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

2015-07-13 Thread Martin André

On Tue, Jul 14, 2015 at 11:40 AM, Steven Dake (stdake) std...@cisco.com
wrote:

  Hey folks,

  I am proposing Paul Bourke for the Kolla core team.  He did a fantastic
 job getting Kolla into shape to support multiple distros and from
 source/from binary installation.  His statistics are fantastic including
 both code and reviews.  His reviews are not only voluminous, but
 consistently good.  Paul is helping on many fronts and I would feel make a
 fantastic addition to our core reviewer team.

  Consider my proposal to count as one +1 vote.

  Any Kolla core is free to vote +1, abstain, or vote –1.  A –1 vote is a
 veto for the candidate, so if you are on the fence, best to abstain :)  We
 require 3 core reviewer votes to approve a candidate.  I will leave the
 voting open until July 20th  UTC.  If the vote is unanimous prior to
 that time or a veto vote is received, I’ll close voting and make
 appropriate adjustments to the gerrit groups.

  Regards
 -steve


+1
No hesitation, Paul's contribution have always been excellent.

Martin


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


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

Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal withHyper

2015-07-13 Thread Peng Zhao

Thanks Adrian!


Hi, all,


Let me recap what is hyper and the idea of hyperstack. 


Hyper is a single-host runtime engine. Technically, 
Docker = LXC + AUFS
Hyper = Hypervisor + AUFS
where AUFS is the Docker image. Due to the shared-kernel nature of LXC, Docker 
lacks of the necessary isolation in a multi-tenant CaaS platform, and this is 
what Hyper/hypervisor is good at.


And because of this, most CaaS today run on top of IaaS: 
https://trello-attachments.s3.amazonaws.com/55545e127c7cbe0ec5b82f2b/388x275/e286dea1266b46c1999d566b0f9e326b/iaas.png
Hyper enables the native, secure, bare-metal CaaS  
https://trello-attachments.s3.amazonaws.com/55545e127c7cbe0ec5b82f2b/395x244/828ad577dafb3f357e95899e962651b2/caas.png


From the tech stack perspective, Hyperstack turns Magnum o run in parallel with 
Nova, not running on atop.


Best,
Peng
 
-- Original --
From:  Adrian Ottoadrian.o...@rackspace.com;
Date:  Tue, Jul 14, 2015 07:18 AM
To:  OpenStack Development Mailing List (not for usage 
questions)openstack-dev@lists.openstack.org; 

Subject:  Re: [openstack-dev] [magnum][bp] Power Magnum to run on metal 
withHyper

 
 Team, 
 
 I woud like to ask for your input about adding support for Hyper in Magnum:
 
 
 https://blueprints.launchpad.net/magnum/+spec/hyperstack
 
 
 We touched on this in our last team meeting, and it was apparent that 
achieving a higher level of understanding of the technology before weighing in 
about the directional approval of this blueprint. Peng Zhao and Xu Wang have 
graciously agreed  to respond to this thread to address questions about how the 
technology works, and how it could be integrated with Magnum.
 
 
 Please take a moment to review the blueprint, and ask your questions here on 
this thread.
 
 
 Thanks,
 
 
 Adrian Otto
 
 
   On Jul 2, 2015, at 8:48 PM, Peng Zhao p...@hyper.sh wrote:
 
  Here is the bp of Magnum+Hyper+Metal integration: 
https://blueprints.launchpad.net/magnum/+spec/hyperstack
 
 
 Wanted to hear more thoughts and kickstart some brainstorming.
 
 
 Thanks,
 Peng
 
 
 -
 Hyper - Make VM run like Container
 
 
  
   __
 OpenStack  Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Cross-Project meeting, Tue July 14th, 21:00 UTC

2015-07-13 Thread Nikhil Komawar

Dear PTLs, cross-project liaisons and anyone else interested,

We'll have a cross-project meeting today at 21:00 UTC, with the
following agenda:

  * Team announcements (horizontal, vertical, diagonal)
  * (OpenStack spec) Replace eventlet + monkey-patching with ?? [1]
  * (OpenStack spec) starting discussion spec for Service Catalog
updates [2]
  * Open Discussion

[1] https://review.openstack.org/#/c/164035
[2] https://review.openstack.org/#/c/181393

If you're from an horizontal team (Release management, QA, Infra, Docs,
Security, I18n...) or a vertical team (Nova, Swift, Keystone...) and
have something to communicate to the other teams, feel free to abuse the
relevant sections of that meeting and make sure it gets #info-ed by the
meetbot in the meeting summary.

See you there !

For more details on this meeting, please see:
https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting

-- 

Thanks,
Nikhil


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

[openstack-dev] [keystone] the status of ec2 api

2015-07-13 Thread Ken'ichi Ohmichi

Hi Keystone team,

Now the test of ec2 credentials[1] is been proposed to Tempest, and
I'd like to know current situation of ec2 api on Keystone as a Tempest
reviewer.

On Nova instead, ec2 api is deprecated in Nova and the standalone
service of ec2 api is separated from Nova to
https://github.com/stackforge/ec2-api .
As the result, ec2 api tests of Nova are defined as thirdparty and
these tests don't run on normal checks/gates on the gate.
If ec2 api is deprecated on Keystone side also, it seems better to
define these tests as thirdparty.
That is a reason why I'd like to know current situation of Keystone ec2 api.

Thanks
Ken Ohmichi

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

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

Re: [openstack-dev] [neutron] Adding results to extension callbacks (ml2 port_update ext handling).

2015-07-13 Thread Miguel Angel Ajo

Inline reply (I've added to CC relevant people for ml2/plugin.py 
port_update extension
handing -via git blame-) as they probably have an opinion here 
(specially the last

two options).

Kevin Benton wrote:

This sounds like a lot of overlap with the dict extend functions. Why
weren't they adequate for the QoS use case?


Let me explain, I believe Mike exceeded the proposal with AFTER_READ, 
that's not the plan,

even if we could do as he proposed,

AFTER_READ dict extension is just a temporary workaround until we have a 
separate explicit
api @armax is working on. Making explicit that your service is going to 
extend resources,

and handled that in an ordered way is a good thing.

Afterwards, the source of this review has came from ML2 implementation of
AFTER_CREATE/AFTER_UPDATE notification for ports/nets.

Let me explain:

 As a decoupled, mixinless service extending core resources, we 
need to do two things:


1) Extending the core resources as other extensions would do, adding 
stuff to the port/network
dicts, here's where it comes the current AFTER_READ dict extension, and 
future API making

that more explicit and more controlled.

2) Verifying the extended values we receive on core resources, by 
registering to BEFORE_*
callbacks. For example, if a tenant is trying to use a qos_profile_id he 
doesn't have access to,

or that doesn't exist, we can cancel the operation by throwing an exception.

  We need to extend the notifications for ports and networks, as 
that's not notified currently.

Mike will work on that too in a separate patch.


3) Taking the finally extended values and store associations in database
 (AFTER_UPDATE/AFTER_CREATE) so any later reads of the port/network 
will get the right

 qos_profile_later in after read.


We have found that AFTER_CREATE/AFTER_UPDATE happens at plugin level
(neutron/plugins/ml2/plugin.py / update_port) and that information 
passed down is
very brief to our case (basically a None port if no ml2-know attribute 
is changed), and

ml2 has to be aware of every single extension.

Here there are two options:
   a) we make ml2 also aware of qos_profile_id changes, complicating 
the business logic down

there, or...

   b) we send the AFTER_CREATE/UPDATE events, and we listen to the callback
listeners to such notification, and they will tell us if there's any 
relevant field which must
be propagated down to agents. Then it's up to the agents to use such 
field or not.



   Mike's patch proposal is in the direction of (b), he's a long term 
thinker, I was proposing him

to just go (a) for now, but let's discuss and find what's more right.



On Mon, Jul 13, 2015 at 7:58 AM, Mike Kolesnikmkole...@redhat.com  wrote:


Hi,

I sent a simple patch to check the possibility to add results to callbacks:
https://review.openstack.org/#/c/201127/

This will allow us to decouple the callback logic from the ML2 plugin in
the QoS scenario where we need to update the agents in case the profile_id
on a port/network changes.
It will also allow for a cleaner way to extend resource attributes as
AFTER_READ callbacks can return a dict of fields to add to the original
resource instead of mutating it directly.

Please let me know what you think of this idea.

Regards,
Mike


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





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



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

Re: [openstack-dev] [Sahara] Questions about how Sahara use trust ?

2015-07-13 Thread michael mccune


On 07/13/2015 09:40 PM, Li, Chen wrote:

Hi mike,

Thanks, this is very helpful.

Summary:

1. The purpose of admin user  proxy user are the same =  to work without user's 
own username  password.


sort of, the proxy user is to work without the user's credentials, 
whereas the admin user needs a trust to operate on the user's project 
resources (clusters).



2. For transient cluster, what sahara need is to be able to operate.


correct.


3. For swift access , using user's own credentials is not safe.  Because the credentials  
is not used by sahara only, it will appear in user space (on the cluster 
nodes) at end.
 Using admin user is silly, doesn't gain any benefit, but create a more 
huge risk.


correct.


=  proxy user must(better to) use proxy user, for security reason.
=  transient cluster can work both way, but proxy user introduce extra effect 
which is not nessary, so admin user is enough.


i would say that is accurate.

mike

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

Re: [openstack-dev] version cap on libs

2015-07-13 Thread Robert Collins

Well FWIW I think that that should go ahead: we have no constraints
mechanism to keep to known-good versions for kilo, and the minimum
version bump was explains in the requirements repo when it was
proposed.

On 14 July 2015 at 17:10, Takashi Yamamoto yamam...@midokura.com wrote:
 hi,

 what's the status of patches like this?
 https://review.openstack.org/#/c/173834/

 we still haven't decided how to handle that?

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



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

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

Re: [openstack-dev] [magnum] The way magnum-conductor communicates with k8s master

2015-07-13 Thread Steven Dake (stdake)

From: OTSUKA, Motohiro yuany...@oeilvert.orgmailto:yuany...@oeilvert.org
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, July 13, 2015 at 8:11 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [magnum] The way magnum-conductor communicates 
with k8s master

Hi, Wanghua

  Currently magnum-conductor can communicates with k8s master which has a 
floating ip in all-in-one deployment. But if magnum-conductor is not deployed 
on the neutron network node which has the br-ex, how can magnum-conductor 
communicate with k8s master. The magnum-conductor node then has no access to 
the k8s master.
Currently this is a limitation of our architecture.

The floating IP is a public routed network, so it should be able to communicate 
in a properly setup cloud.

  Another question:
  Magnum-conductor only communicate with k8s master, why k8s minion has a 
floating ip too? What is the floating ip of k8s minion used for?

I think, there is no reason.
Historically, Our heat template come from larsks/heat-kubernetes [1] template.
larsks/heat-kubernetes provides floating ip to minion nodes, this is just a 
reason.

The minion floating ips are needed to access the micro-service front ends from 
the internet.

Regards
-steve

[1]: https://github.com/larsks/heat-kubernetes

Thanks
-Yuanying

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

Re: [openstack-dev] [murano] [congress] Congress needs to fetch environments from all tenants.

2015-07-13 Thread Filip Blaha

Hi Tim,

The change was already merged to master. Withe next release of
python-muranoclient it can be used in Congress.

Regards
Filip

On 07/08/2015 03:57 PM, Tim Hinrichs wrote:

There are two things to remember here.

1) When you configure the Congress datasource driver to talk to
Murano, you choose which user rights Congress should use. If you need
to get all of the tenants data, you want to choose an admin user for
the Murano driver. Personally I always use admin users so that I can
write policy over everything. Typically we think of Congress as an
admin tool.

2) As you point out, if the Murano driver doesn't provide
all_tenants=true argument when it makes the API call into Murano, it
won't get all the data for all the tenants; it'll only get the data
for the user you provided in (1). Ideally whether all_tenants=true
would be a datasource configuration option, but it's not today. The
datasource drivers I've looked at all use all_tenants=true.

Tim

On Wed, Jul 8, 2015 at 5:16 AM Kirill Zaitsev kzait...@mirantis.com
mailto:kzait...@mirantis.com wrote:

1) This does raise a security concern. We can however cover it
with a separate policy-based permission, that would check if a
user can view all tenants. nova seem to do so, see:

https://github.com/openstack/nova/blob/4209d0140774adf3e162b7bde3cbd6b417065dd5/etc/nova/policy.json#L13

2) Will give it some thought, but it does seem like an ok practice.

--
Kirill Zaitsev

Murano team
Software Engineer
Mirantis, Inc

On 8 Jul 2015 at 14:44:51, Filip Blaha (filip.bl...@hp.com
mailto:filip.bl...@hp.com) wrote:

Hi all,

I started implement bp [1]. Problem is that congress needs data
about
environments from all tenants but murano API lists only
environments of
user's current tenant. We decided to ipmplement it similarly like
listing servers in nova where is query parameter all_tenants=true
for
that (user must be admin) I have 2 questions about that:

1) Are there any security concerns about this approach?
2) Has someone better idea how to implement this?

[1]
https://blueprints.launchpad.net/murano/+spec/murano-api-all-tenants-search

Regards
Filip

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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

[openstack-dev] [puppet] weekly meeting #42

Hello Puppet masters!

Here's an initial agenda for our weekly meeting, tomorrow at 1500 UTC
in #openstack-meeting-4:

https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150714

Please add additional items you'd like to discuss.
If our schedule allows it, we'll make bug triage during the meeting.

See you there!
-- 
Emilien Macchi



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

Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master

2015-07-13 Thread Doug Hellmann

Excerpts from Jeremy Stanley's message of 2015-07-13 11:57:35 +:
 On 2015-07-13 10:08:16 +0200 (+0200), Ihar Hrachyshka wrote:
  clients and oslo libraries still maintain their py26 for a reason:
  decision to drop py26 was for server projects only.
 
 Yes, that decision was made at a time when our server projects had
 stable branches, but our clients and shared libraries did not. My
 recollection is that server projects only was a proxy for only
 projects with stable branches. Now that we have stable branches of,
 say, python-novaclient where we can backport juno-relevant security
 fixes, people on 2.6-only platforms who want to install and run
 python-novaclient from PyPI can use the stable/juno version (though
 I'll admit that finding which version works with 2.6 may be a tricky
 proposition for a consumer who is unaware of this situation).

Yes, that's my recollection, too. I'm also a bit worried about the PyPI
situation, since pip doesn't automatically detect that a version of a
package is incompatible with the current version of python.

The etherpad Dims linked to [1] proposes looking at the PyPI stats for
client downloads. If those look relatively low, I would feel more
confident in dropping 2.6 support in the master branch of the clients,
with major version updates to indicate that.

On the other hand, how much longer will we be supporting Juno? A
matter of months, right?

Doug

[1] https://etherpad.openstack.org/p/juno-cross-project-future-of-python

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

[openstack-dev] [neutron] Adding results to extension callbacks

2015-07-13 Thread Mike Kolesnik

Hi, 

I sent a simple patch to check the possibility to add results to callbacks: 
https://review.openstack.org/#/c/201127/ 

This will allow us to decouple the callback logic from the ML2 plugin in the 
QoS scenario where we need to update the agents in case the profile_id on a 
port/network changes. 
It will also allow for a cleaner way to extend resource attributes as 
AFTER_READ callbacks can return a dict of fields to add to the original 
resource instead of mutating it directly. 

Please let me know what you think of this idea. 

Regards, 
Mike 

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

Re: [openstack-dev] [neutron][upgrades] Potential issues when performing Neutron upgrades

2015-07-13 Thread Russell Bryant

On 07/13/2015 04:09 AM, Kevin Benton wrote:
because you won't have to run Neutron agents on compute nodes anymore.
 
 How will upgrades work for OVN?

We haven't written anything down yet, but here's what I expect.

Right now we're still changing the db schema however is needed without
messing with versioning.  As we get to production ready, I expect
we'll start being strict about only making backwards compatible ovsdb
schema changes to make upgrades easier.

There are 2 central components - ovn-northd and ovsdb-server - that
would be upgraded first, which I would expect to be done at the same
time as upgrading your Neutron control plane.  As long as any ovsdb
schema changes are backwards compatible, you could do rolling-upgrades
of ovn-controller on compute or network nodes.

-- 
Russell Bryant

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

Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master




On 7/13/2015 6:57 AM, Jeremy Stanley wrote:

On 2015-07-13 10:08:16 +0200 (+0200), Ihar Hrachyshka wrote:

clients and oslo libraries still maintain their py26 for a reason:
decision to drop py26 was for server projects only.


Yes, that decision was made at a time when our server projects had
stable branches, but our clients and shared libraries did not. My
recollection is that server projects only was a proxy for only
projects with stable branches. Now that we have stable branches of,
say, python-novaclient where we can backport juno-relevant security
fixes, people on 2.6-only platforms who want to install and run
python-novaclient from PyPI can use the stable/juno version (though
I'll admit that finding which version works with 2.6 may be a tricky
proposition for a consumer who is unaware of this situation).



Taking python-novaclient as an example, there is still a gating py26 job 
on that project, so it still works.


If/when we drop py26 support for a client, we could tag that commit and 
then people wanting to use the client on py26 could build a package from 
before that tag and then lay down whatever other patches they needed.


Tempest is already sort of doing some things like this with tagging 
milestones due to the branchless nature of Tempest, so it seems the same 
idea could be carried over to the clients in cases like this.


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [Murano] Versioning of Murano packages and MuranoPL classes

2015-07-13 Thread Georgy Okrokvertskhov

On Mon, Jul 13, 2015 at 2:19 AM, Alexander Tivelkov ativel...@mirantis.com
wrote:

 Hi Gosha,

 Supporting versioning in existing backend will require us to re-implement
 the significant part of Artifact Repository in Murano API: we'll need to
 add versions and dependencies concepts into our model (which is already
 complicated and dirty enough), extend appropriate API calls etc. And all
 the efforts will be a waste of time once we finally migrate to Artifacts.

 Also, what do you mean by set by default? V3 API is experimental, but it
 is already merged into upstream Glance, so there is no problem with using
 it in Murano right away.

 This is exactly why I have these concerns. I wonder how much customers
will use experimental API in production. I just don't want to add extra
block on Murano adoption way.



 --
 Regards,
 Alexander Tivelkov

 On Fri, Jul 10, 2015 at 5:56 PM, Georgy Okrokvertskhov 
 gokrokvertsk...@mirantis.com wrote:

 Hi Alex,

 Thank you for the great summary.

 I have a concern about item #8. Can we add an option to Murano to use
 previous storage engine rather then Glance v3? We need to make sure that v3
 API in Glance is set by default before we do a hard dependency on it in
 Murano.

 Thanks
 Gosha

 On Fri, Jul 10, 2015 at 4:53 AM, Alexander Tivelkov 
 ativel...@mirantis.com wrote:

 Hi folks,

 Ability to manage multiple versions of application packages and their
 dependencies was always an important item in Murano roadmap, however we
 still don't have a clear spec for this feature.
 Yesterday we hosted a small design session to come up with a plan on
 what can be done in Liberty timeframe to have proper versioning for
 MuranoPL classes and packages. Stan Lagun, Kirill Zaitsev and myself
 participated offline, some other muranoers joined remotely. Thanks to
 everybody who joined us.

 TL;DR: it turns out that now we have a clear plan which will allow us to
 achieve proper versioning of the packages and classes, and we'll try to
 implement the most important parts of it in Liberty.

 Here is the detailed outcome of the session:


1. We'll use the standard Semantic Versioning format
('Major.Minor.Patch[-dev-build.label[+metadata.label]]') to version our
packages: changes which break backwards-compatibility should increment 
 the
major segment, non-breaking new features increment the minor segment and
all non-breaking bugfixes increment the patch segment. The developers
should be carefull with the new features part: if you add a new method 
 to
a class, it may be considered a breaking change if the existing 
 subclasses
of this class have the same method already declared. We still assume that
such changes should lead to increment of 'minor' segment, however it is 
 up
to best judgement of developers in particular case: if the risk of such
method override is really high it may worth to increment the 'major'
segment. Proper guideline on the versioning rules will be published 
 closer
to L release.

2. A new field 'Version' is introduced into package manifest file
which should define package version in complete semver format. The field
itself is optional (so existing apps are not broken), if it is not
specified the package is assumed to have version '0.0.0'

3. The existing 'Require' block of Application manifest will be used
to specify the package dependencies. Currently it is a yaml-based
dictionary, with the keys set to fully-qualified names of the dependency
packages and the values set to the version of those dependencies. 
 Currently
this block is used only for integration with apps stored at
apps.openstack.org. It is suggested to use this block in the
deployment process as well, and extend its semantics.
The version of the dependency specified there should also follow the
semver notation, however it may be specified in the shortened format, 
 i.e.
without specifying the 'patch' or 'patch' and 'minior' components. In 
 this
case the dependency will be specified as a range of allowed versions. For
example, a dependency version 1.2 will mean a (1.2.0 = version  1.3)
range.
If the version of a dependency is not specified (like in this
existing app - [1]) then we assume the version 0 - i.e. the last
available pre-release version of a package.

4. Murano core library is also a package which has its own version.
The current one is assumed to have a version 0.1.0, the one which is 
 going
to be released in L will be probably called 0.2.0. The lib is still 
 quickly
evolving, so we are not releasing a 1.0.0 until we are sure that we are 
 not
going to have any breaking changes anytime soon.
As with any other package it will be possible to have several
versions of the Core Library installed in Murano at the same moment of 
 time.

5. There is no mandatory need to add the the dependency on the core
library to the Requires

[openstack-dev] global-requirements sync not happening on stable/kilo? reqs check job busted?

From what I can tell, nova never got a global-requirements sync update 
for this change on stable/kilo:


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

We need that so we don't have to try and do it manually:

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

Which is apparently busted in the gate-nova-requirements job:

http://logs.openstack.org/80/200880/1/check/gate-nova-requirements/461f83f/console.html#_2015-07-12_12_28_17_768

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master

On 2015-07-13 09:39:36 -0400 (-0400), Doug Hellmann wrote:
[...]
 On the other hand, how much longer will we be supporting Juno? A
 matter of months, right?

The reason it's being brought up again at this point is to ask
whether it's more important that we keep master clients/libs working
with 2.6 for several more months, or be able to push forward with
our constraints overhaul between now and then. I'll be hard to have
the necessary tooling in place before the liberty release if we
can't actually use it before then (since that's roughly when juno
EOL is scheduled).
-- 
Jeremy Stanley

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

Re: [openstack-dev] [nova][qa] turbo-hipster seems to be out to lunch




On 7/12/2015 1:50 AM, Joshua Hesketh wrote:

Hey,

Yes, sorry, I only discovered this yesterday. I should have updated the
wiki page sooner but I've placed some details there now:
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/kilo+topic:fix-th,n,z

Basically the removal of migrate-flavor-data from master broke
turbo-hipster and a few of the patches to make it work just missed the
cut-off for kilo. As such they are backported here:
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/kilo+topic:fix-th,n,z

Turbo-hipster is now disabled, blocked on getting those in so any help
reviewing would be appreciated.

Thanks,
Josh


On Sat, Jul 11, 2015 at 9:09 AM, Matt Riedemann
mrie...@linux.vnet.ibm.com mailto:mrie...@linux.vnet.ibm.com wrote:

There are a lot of failures on nova changes since yesterday and
rechecks today don't seem to be coming back (after rechecking
several hours ago).

Known issues?

--

Thanks,

Matt Riedemann


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




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



Thanks for the summary.  I'll work on getting these in today which 
includes getting the g-r sync and requirements jobs working again on 
stable/kilo.  The fix for that is in the gate now and then we'll get the 
proper stuff working in nova stable/kilo to get your cherry picks in.


--

Thanks,

Matt Riedemann


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

[openstack-dev] [FUEL] Nailgun agent master freeze

2015-07-13 Thread Vladimir Sharshov

At the moment everything is ready for moving fuel-web/bin/agent to a
separate git repository.

Please, be informed that all patches changing fuel-web/bin/agent that will
be merged after this moment will need to be ported into the new
nailgun-agent repository.

Current source repository which will be imported to stackforge:
https://github.com/warpc/fuel-nailgun-agent

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

Re: [openstack-dev] [Openstack-operators] [Openstack] Rescinding the M name decision

2015-07-13 Thread Brad Knowles

On Jul 10, 2015, at 4:19 AM, Thierry Carrez thie...@openstack.org wrote:

 I think growing up is accepting the pain that comes with picking a
 good name, rather than sidestepping the issue.

I’ve heard the phrase that there are only two hard problems in computer 
science, and naming is one of them.

Just because it is hard is not a reason to avoid doing it.  Sometimes the fact 
that it is hard is the biggest reason why we should do it, and make sure we do 
it right.


We have a naming scheme, based on letters and the location.

IMO, we should stick with that, we just need to go further down the list on due 
diligence, both from a copyright/trademark/legal perspective as well as 
cultural and other sensitivities that might not have been obvious from the 
beginning.

YMMV.

--
Brad Knowles b...@shub-internet.org
LinkedIn Profile: http://tinyurl.com/y8kpxu



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

Re: [openstack-dev] global-requirements sync not happening on stable/kilo? reqs check job busted?




On 7/13/2015 9:01 AM, Matt Riedemann wrote:

 From what I can tell, nova never got a global-requirements sync update
for this change on stable/kilo:

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

We need that so we don't have to try and do it manually:

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

Which is apparently busted in the gate-nova-requirements job:

http://logs.openstack.org/80/200880/1/check/gate-nova-requirements/461f83f/console.html#_2015-07-12_12_28_17_768




Looks like we need this:

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

--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] [puppet] First Sprint proposal

I just closed the poll after one week.
It will happen on Wed 9/2 – Fri 9/4.

We'll work on the agenda during the following weeks.

Best,

On 07/06/2015 10:26 PM, Matt Fischer wrote:
 Operators mid-cycle is Aug 17-21 at a TBD location, I voted accordingly.
 Thanks.
 
 On Mon, Jul 6, 2015 at 12:09 PM, Emilien Macchi emil...@redhat.com
 mailto:emil...@redhat.com wrote:
 
 
 
 On 07/06/2015 02:05 PM, Matt Fischer wrote:
  I think this is a great idea. I'd like to get a firm date on the
  operators mid-cycle before I vote though.
 
 If it overlaps, we can add more slots. Feel free to ping me on IRC for
 that, I'll update the doodle.
 
 Thanks,
 
 
  On Mon, Jul 6, 2015 at 11:31 AM, Emilien Macchi emil...@redhat.com 
 mailto:emil...@redhat.com
  mailto:emil...@redhat.com mailto:emil...@redhat.com wrote:
 
  Hi,
 
  I would like to organize our first sprint for contributing to our 
 Puppet
  OpenStack modules. It will happen in Red Hat Montreal (Canada) 
 office,
  during 3 days.
 
  If you're interested to participate, please find the slots that may 
 work
  for you [1]. Any slot suggestion is welcome though.
  Also, please bring on the etherpad any topics we should work on 
 together
  [2].
  We will groom topics during a meeting and prepare the agenda before 
 the
  sprint.
 
  [1] http://doodle.com/xk2sfgu4xsi4y6n4r46t7u9k
  [2] https://etherpad.openstack.org/p/puppet-liberty-mid-cycle
 
  Regards,
  --
  Emilien Macchi
 
 
  
 __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

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

-- 
Emilien Macchi



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

Re: [openstack-dev] [openstack-announce] End of life for managed stable/icehouse branches

On 2015-07-14 00:33:52 +0200 (+0200), Thomas Goirand wrote:
[...]
 I believe I asked you about 10 times to keep these branches alive, so
 that distributions could work together on a longer support, even without
 a CI behind it.

And the project consensus has seemed to disagree with this after
careful discussion, each time it's brought up. Distributions
collaborating upstream on stable branch support would entail helping
keep those branches tested upstream. As a project we've consistently
stated that publishing updates to stable branches without sufficient
testing is an affront to our quality assurance stance. The final
state of the upstream stable/icehouse branch, as with each previous
stable branch all the way back to stable/diablo, is tagged in the
repository so that you can construct your own continuation of
stable/icehouse from the same point as needed.

 I have also asked for a private gerrit for maintaining the Icehouse
 patches after EOL.
[...]

I do apologize for not setting up a separate private Gerrit instance
for embargoed security fix code reviewing. It would be a help to me
and the rest of the VMT to have it, I simply haven't had the
available time I'd hoped to be able to work out remaining
implementation details for deploying and maintaining it. That said,
its priority has decreased as the VMT is trying to get a little more
cautious about only embargoing vulnerability reports that actually
benefit enough from a brief advance notice to downstream
stakeholders to offset the significant cost in efficiency of the
embargo process (only a small amount of which is due to the tools we
end up using for private code review).

However, as I explained to you at the Liberty Design Summit after
discussion with members of the infrastructure team, we're also not
comfortable maintaining stable branches of projects in a private
Gerrit instance any longer than we do in the normal public one, and
would want to remove inactive branches from it at the same time
their public counterparts reach end of life.

Since I feel like I'm starting to repeat myself at this point, I'll
leave it to others to continue the thread this time. If you're
interested in overhauling the stable branch EOL process (I didn't
design and plan it, I merely pull the levers and push the buttons),
that discussion should involve the stable branch release managers
and the rest of the release team along with the quality assurance
team.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [neutron] - Proposing Miguel Angel Ajo for the Control Plane core team

2015-07-13 Thread Miguel Angel Ajo


Thanks Kevin and everybody for the positive feedback! :)

It's a pleasure to work with so many awesome people.

Best,
Miguel Ángel,



Kevin Benton wrote:

It's been a week with no negative feedback. Welcome to the team Miguel!
On Jul 7, 2015 5:22 AM, Ihar Hrachyshkaihrac...@redhat.com  wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Oh yes!

It was a bit weird that Miguel, while owning a feature branch, did not
have a say in what is merged there. Now it should be more in line with
his actual position in the project.

Good work, Miguel!

On 07/06/2015 01:02 PM, Kevin Benton wrote:

Hello!

As the Lieutenant of the built-in control plane[1], I am proposing
to add Miguel Angel Ajo to the control plane core reviewer team.

His review stats are inline with the other core reviewers[2], and
his work on improving the stability/performance of the agents over
the last year has been important in making the reference
implementation reliable.

Existing cores, please vote +1/-1 for his addition to the team.

Cheers!

1.
http://docs.openstack.org/developer/neutron/policies/core-reviewers.ht

ml
2. http://stackalytics.com/report/contribution/neutron/30
http://stackalytics.com/report/contribution/neutron/60
http://stackalytics.com/report/contribution/neutron/90

-- Kevin Benton



__


OpenStack Development Mailing List (not for usage questions)

Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVm7WcAAoJEC5aWaUY1u57RUoH/jIimjwrLqzzq8u0Ix25YGrR
CQVkLGbE7j+LtzvKOcFSORp/Y/gwsJ6KF3B7NBqfh1C0fHx/uMVp/tf7/NhuthE0
7+gsMe3yn6oOraYCQHwEDHpxz6r+7dmMfhisknH5k7vsdnwNi5CrnXyr+knxrQ0L
jjFvdi3F/+2ztV5LtPJLPoU72d81ATwEEFTH/9vUeFPlBu8okUuXRszPJCWR3MeL
PrKeg5G6OH4b4GVC45Q7238rWB7uiwfFLILo9I8qwgJ/LZnKkK12bmk3tUgE3cqP
BXxfuMKueJgOvRU0VPpWZwXicf2/pOmdUBv7uX+BeK9hPP5G9i8ITmFblB+doUk=
=EuZs
-END PGP SIGNATURE-

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



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



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

[openstack-dev] [puppet] puppet-designate POC implementation of virtualenv and docker support.

2015-07-13 Thread Clayton O'Neill

Last year I put together a virtualenv patch for the Designate puppet
module, but the patch was too invasive of a change and too opinionated to
be practical to merge.  I've taken another shot at this with the approach
of implementing well defined hooks for various phases of the module. This
should  allow external support for alternative ways of installing and
running services (such as virtualenv, and docker).  I think this patch is
now mostly ready for some outside reviews (we'll be running the virtualenv
support in production soon).

The puppet-designate change to support this can be found here:
https://review.openstack.org/#/c/197172/

The supporting puppet-designate_ext module can be found here:
https://github.com/twc-openstack/puppet-designate_ext

The basic approach is to split the module dependency chain into 3 phases:

 * install begin/end
 * config begin/end
 * service begin/end

Each of these phases have a pair of corresponding anchors that are used
internally for dependencies and notifications.  This allows external
modules to hook into this flow without having to change the module.  For
example, the virtualenv support will build the virtualenv environment
between the designate::install::begin and designate::install::end anchors.
Additionally, the virtualenv support will notify the
designate::install::end anchor.  This allows other resources to subscribe
to this anchor without needing to know if the software is being installed
as a package, virtualenv, or docker image.

I think this approach could be applied mostly as is to at least some of the
existing modules with similar levels of changes.  For example, horizon,
keystone  heat would probably be fairly straightforward.  I suspect this
approach would need refinement for more complex services like neutron and
nova.  We would need to work out how to manage things like external
packages that would still be needed if running a virtualenv based install,
but probably not needed if running a docker based install.  We would
probably also want to consider how to be more granular about service
notifications.

I'd love to get some feedback on this approach if people have time to look
it over.  We're still trying to move away from using packages for service
installs and I'd like to figure out how to do that without carrying
heavyweight and fragile patches to the openstack puppet modules.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core

2015-07-13 Thread Steven Dake (stdake)

Hey folks,

I am proposing Paul Bourke for the Kolla core team.  He did a fantastic job 
getting Kolla into shape to support multiple distros and from source/from 
binary installation.  His statistics are fantastic including both code and 
reviews.  His reviews are not only voluminous, but consistently good.  Paul is 
helping on many fronts and I would feel make a fantastic addition to our core 
reviewer team.

Consider my proposal to count as one +1 vote.

Any Kolla core is free to vote +1, abstain, or vote –1.  A –1 vote is a veto 
for the candidate, so if you are on the fence, best to abstain :)  We require 3 
core reviewer votes to approve a candidate.  I will leave the voting open until 
July 20th  UTC.  If the vote is unanimous prior to that time or a veto vote 
is received, I’ll close voting and make appropriate adjustments to the gerrit 
groups.

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

Re: [openstack-dev] [keystone] Liberty SFE Request - Dynamic Policies

2015-07-13 Thread Adam Young


On 07/03/2015 08:36 AM, Samuel de Medeiros Queiroz wrote:

Hi Thierry,

Thanks for clarifying. A Spec Freeze Exception is what I was supposed 
to ask for.


Rectifying:

On behalf of the team working on the Dynamic Policies subject, I would 
like to ask for a *Spec Freeze Exception* in Liberty for it.


This one is an important lead in to a lot of other work. Getting just 
this in to Liberty allows us to focus the remainder of the work on 
Dynamic policy inside Keystone.


Please approve.




Thanks,
Samuel de Medeiros Queiroz


Thierry Carrez wrote:

samuel wrote:

[...]
On behalf of the team working on the Dynamic Policies subject, I would
like to ask for a Feature Freeze Exception in Liberty for it.

Liberty Feature Freeze is on September 3rd, so I doubt you need a
feature freeze exception at this time. I suspect that would be a spec
freeze exception or some other Keystone-specific freeze exception ?

https://wiki.openstack.org/wiki/FeatureFreeze





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


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

Re: [openstack-dev] [Ironic] how about those alternating meeting times?

2015-07-13 Thread Jim Rollenhagen

On Mon, Jul 13, 2015 at 06:41:55PM +, Devananda van der Veen wrote:
 This is a much-overdue follow up to this poll, which got 17 responses.
 
 snip
 
 So, though it saddens me, I would like to propose that we change back to a
 single meeting time effective the week following our midcycle (Aug 10th).
 That will give folks two meetings in each timeslot between now and then to
 become aware of, and raise any issues with, this change.
 

+1 for moving back to single meeting time, +2 for this being sad. I
really wish we could include folks in those timezones, but it has proven
to be mostly ineffective within the project.

// jim

 
 Regards,
 Devananda
 
 
 On Mon, May 11, 2015 at 6:14 PM Michael Davies mich...@the-davies.net
 wrote:
 
  On Tue, May 12, 2015 at 9:08 AM, Ruby Loo rlooya...@gmail.com wrote:
 
  Maybe the question is better posed to those folks -- was it useful or
  not? And if not, why? Because the date/time still didn't work, or because
  not enough (or the right persons) weren't there so their issues of interest
  weren't discussed, or they wouldn't have attended anyway, or ? And if it
  was useful, for how many was it useful? (Devananda's poll will capture some
  of that info.)
 
 
  I found it useful - it's nice to be awake at meeting time :)
 
  There's certainly a subset of the team that I never overlap with now,
  which is a shame, but timezones present challenges for a geographically
  dispersed team.
 
  Previously the meeting was at 4:30am (or 5:30am depending upon daylight
  savings), which was quite hard, but I did make it most weeks.  The new
  timeslot of 2:30am/pm (3:30am/pm) is certainly only achievable for me every
  other week (no surprises for guessing which one :)
 
  I think it's great that we try and accommodate contributors from all
  around the globe!
 
  Michael...
  --
  Michael Davies   mich...@the-davies.net
  Rackspace Cloud Builders Australia
   __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

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


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

Re: [openstack-dev] [keystone] Liberty SFE Request -DynamicPolicies

2015-07-13 Thread Brad Topol

I am a +1 on this as well. I agree with Guang


Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680



From:   Yee, Guang guang@hp.com
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Date:   07/13/2015 02:24 PM
Subject:Re: [openstack-dev] [keystone] Liberty SFE Request - 
Dynamic Policies



++!
 
Per my understanding, the work, and therefore the risks, are fairly 
compartmentalized. The upside is this will pave the way for a much richer 
authorization management system. 
 
 
Guang
 
From: Adam Young [mailto:ayo...@redhat.com] 
Sent: Monday, July 13, 2015 10:15 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [keystone] Liberty SFE Request - Dynamic 
Policies
 
On 07/03/2015 08:36 AM, Samuel de Medeiros Queiroz wrote:
Hi Thierry,

Thanks for clarifying. A Spec Freeze Exception is what I was supposed to 
ask for.

Rectifying:

On behalf of the team working on the Dynamic Policies subject, I would 
like to ask for a *Spec Freeze Exception* in Liberty for it.

This one is an important lead in to a lot of other work. Getting just this 
in to Liberty allows us to focus the remainder of the work on Dynamic 
policy inside Keystone.

Please approve.




Thanks,
Samuel de Medeiros Queiroz

Thierry Carrez wrote:
samuel wrote:
[...]
On behalf of the team working on the Dynamic Policies subject, I would
like to ask for a Feature Freeze Exception in Liberty for it.
Liberty Feature Freeze is on September 3rd, so I doubt you need a
feature freeze exception at this time. I suspect that would be a spec
freeze exception or some other Keystone-specific freeze exception ?
 
https://wiki.openstack.org/wiki/FeatureFreeze
 




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




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

Re: [openstack-dev] [Cinder] python-cinderclient functional tests

2015-07-13 Thread Mike Perez

On 16:28 Jul 10, Ivan Kolodyazhny wrote:
 Hi Mike,
 
 Unfortunately, we don't get a lot of stats [1] because we don't run it
 often. I've added 'check experimental' comment to latest
 python-cinderclient review request to get more stats.
 
 Review request to make this voting: https://review.openstack.org/#/c/200522/
 
 [1]
 http://graphite.openstack.org/render/?width=877height=548_salt=1436533755.887from=00%3A00_20150524until=23%3A59_20150710target=stats.zuul.pipeline.experimental.job.check-cinderclient-dsvm-functional.FAILUREtarget=stats.zuul.pipeline.experimental.job.check-cinderclient-dsvm-functional.SUCCESStarget=stats.zuul.pipeline.experimental.openstack.python-cinderclient.total_changestitle=check-cinderclient-dsvm-functional

Add an agenda item to the next Cinder meeting. Sure there should be no
objections.

-- 
Mike Perez

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

Re: [openstack-dev] [glance] Additions and removals for the glance-drivers team



On 7/9/15, 13:37, Flavio Percoco fla...@redhat.com wrote:

Greetings,

I'd like to propose Stuart Mclaren for the glance-drivers team. Stuart
has a huge amount of knowledge about Glance's history, he knows the
Glance codebase well and he also has experience in deploying and
maintaning Glance production environments.

Stuart has shown his interest in joining the team in the past but he's
addition was put on-hold for other reasons. In the hope that Stuart is
still willing to join the team, I'd like to propose him again hoping
this time he'll be added.

In addition to the above, I'd like to propose removing:

- Arnaud Legendre
- Mark Washenberger


Arnaud and Mark, despite their amazing work in the past, are no longer
contributing to Glance at all. I think it's time for us to thank them
again for their contributions and to wish they'll join us again in the
future.

Cheers,
Flavio

-- 
@flaper87
Flavio Percoco

+1 on adding Stuart if he still would like to join.

+1 on removing Arnaud and Mark. While they contributed an immense amount
of what Glance is today, they haven't been active in quite a while. If
they ever do come back, I'd be in favor of adding them back to the drivers
team though.

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

Re: [openstack-dev] [Ironic] how about those alternating meeting times?

2015-07-13 Thread Devananda van der Veen

This is a much-overdue follow up to this poll, which got 17 responses.

TL;DR:

The poll indicated that most responders did not personally find the 0500
meeting helpful. Reviewing the meeting logs for the last six months shows
significantly lower core attendance in those meetings. Informal feedback
confirms both of these conclusions.

As much as I want to be inclusive of contributors for whom the 1700GMT
Monday meetings do not work, I feel that the 0500GMT Tuesday meetings have
not been effective and would like to propose that we change back to a
single meeting time.


Longer summary:

In that poll, I asked four questions to gauge both individual attendance
and benefit, as well as perceived benefit to others. I think the results
are quite interesting. (Note that every question had a free form choice as
well, which I'm not tallying here)

Were you able to attend the meetings?
+4 Yes, I attended most or all of the metings
-10 No. Because of the timing, I was only able to attend half of the
meetings.

Were the alternating times helpful to you personally?
+5 Yes. I attended both Monday and Tuesday meetings and found this split
helpful.
-10 No. I was unable to attend half of the meetings and found some or all
of them to be non-productive.

Do you believe that alternating meeting times was helpful to the project
overall, regardless of your own availability?
+11 Yes
- 4 No

Do you think we should continue to split meeting times?
+10 Yes
-3 No

In the freeform responses, I got suggestions to split out subteams (we've
done this for the neutron integration work), as well as a few comments that
DST impact was significant and preventing attendance to half the meetings,
and suggestions to move the meeting a few hours this way or that way.

Lately, I have missed several of the 0500GMT meetings due to tiredness,
travel, or other things. I notice that very few of the core team are there,
too (many thanks to Jim for consistently being there and leading it when
I'm not). While I think it is important to have a meeting time that serves
Haomeng and Ramki and Michael Davies (and everyone else in APAC), these
meetings do not consistently have a majority of cores present and therefor
can't reasonably make any decisions. And on the flip side, these impact the
1700GMT meetings in that those have lost a lot of momentum, seemingly
because the US/EU regulars miss every other week.

So, though it saddens me, I would like to propose that we change back to a
single meeting time effective the week following our midcycle (Aug 10th).
That will give folks two meetings in each timeslot between now and then to
become aware of, and raise any issues with, this change.


Regards,
Devananda


On Mon, May 11, 2015 at 6:14 PM Michael Davies mich...@the-davies.net
wrote:

 On Tue, May 12, 2015 at 9:08 AM, Ruby Loo rlooya...@gmail.com wrote:

 Maybe the question is better posed to those folks -- was it useful or
 not? And if not, why? Because the date/time still didn't work, or because
 not enough (or the right persons) weren't there so their issues of interest
 weren't discussed, or they wouldn't have attended anyway, or ? And if it
 was useful, for how many was it useful? (Devananda's poll will capture some
 of that info.)


 I found it useful - it's nice to be awake at meeting time :)

 There's certainly a subset of the team that I never overlap with now,
 which is a shame, but timezones present challenges for a geographically
 dispersed team.

 Previously the meeting was at 4:30am (or 5:30am depending upon daylight
 savings), which was quite hard, but I did make it most weeks.  The new
 timeslot of 2:30am/pm (3:30am/pm) is certainly only achievable for me every
 other week (no surprises for guessing which one :)

 I think it's great that we try and accommodate contributors from all
 around the globe!

 Michael...
 --
 Michael Davies   mich...@the-davies.net
 Rackspace Cloud Builders Australia
  __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [Ironic] weekly subteam status report

2015-07-13 Thread Ruby Loo

Hi,

Following is the subteam report for Ironic. As usual, this is pulled
directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)

As of Mon, Jul 13 (diff with Jun 29)

Open: 147 (-3). 6 new (+1), 52 in progress, 1 critical (+1), 10 high (-1)
and 8 incomplete (-1)

Nova bugs with Ironic tag: 24 (+1). 0 new, 0 critical, 0 high


Neutron/Ironic work (jroll)

still looking for spec reviews, have agreement within subteam
- https://review.openstack.org/#/c/188528/ -- I've +2'd this with one
follow-up needed
- https://review.openstack.org/#/c/187829/ -- should be good to go, some
nits to address I think


Oslo (lintan)
==
Graduating fileutils,  https://bugs.launchpad.net/ironic/+bug/1473815


Testing (adam_g/jlvillal)
==
https://review.openstack.org/#/c/166386/ (tempest microversion support) is
still not merged, can we have more resources pointed at it?


Inspector (dtansur)
===
ironic-inspector 2.0.0 released
-
http://lists.openstack.org/pipermail/openstack-announce/2015-July/000432.html
- https://pypi.python.org/pypi/ironic-inspector/2.0.0

proposing to run inspector dsvm check in ironic experimental pipeline
- https://review.openstack.org/#/c/198381/


Bifrost (TheJulia)
=
Considering a change over to utilizing simple-init for network configuration
- https://review.openstack.org/#/c/200834/


Drivers
==

iRMC (naohirot)
-
https://review.openstack.org//#/q/owner:+naohirot%2540jp.fujitsu.com+status:+open,n,z

Status: Reactive (solicit for the final review and approval, started to
write installation guide)
- iRMC Virtual Media Deploy Driver
bp/ipa-as-default-ramdisk

Status: Active (spec and vendor passthru reviews are on going)
- Enhance Power Interface for Soft Reboot and NMI
- bp/enhance-power-interface-for-soft-reboot-and-nmi

Status: Active (code review is on going)
- iRMC out of band inspection
- bp/ironic-node-properties-discovery



Until next week,
--ruby

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

[openstack-dev] [Ironic] Reminder - midcycle Sprint in Seattle Aug 12 - 14

2015-07-13 Thread Devananda van der Veen

Hi all!

Just dropping a reminder out here -- our midcycle is one month away! We're
starting to jot down informal notes and plans on an etherpad here:

https://etherpad.openstack.org/p/ironic-liberty-midcycle

Please continue to use that to coordinate all the things. If you plan to
attend, please make sure you're listed there and then go purchase a free
ticket (one per person) on eventbrite so that I can coordinate with site
facilities and send you any last-minute information about the event.

https://www.eventbrite.com/e/openstack-ironic-sprint-august-2015-tickets-17533862254

Looking forward to seeing ya'll soon!

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

Re: [openstack-dev] [designate][lbaas][GSLB] IRC Meeting Tomorrow - 07/Jul/2015 @ 16:00 UTC

2015-07-13 Thread Hayes, Graham

A quick reminder that we will be reconvening tomorrow at 16:00UTC in 
#openstack-meeting-4 to continue the API discussion.

Thanks,

Graham

On 06/07/15 15:27, Hayes, Graham wrote:
 Hi All,

 I have put up an agenda for the meeting tomorrow:

 https://wiki.openstack.org/wiki/Meetings/GSLB

 It will be in #openstack-meeting-4 @ 16:00 UTC

 I sent around a strawman API doc last week -
 https://docs.google.com/document/d/1nw5jVn0hjmhlhkZJAohx-gqRkkbVhMMJ79Pogd0ysEk/edit?usp=sharing

 Can everyone have a read before the meeting tomorrow?

 Thanks,

 Graham Hayes

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



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

Re: [openstack-dev] [puppet] new etherpad to track Puppet OpenStack CI work

2015-07-13 Thread Paul Belanger


On 07/13/2015 02:21 PM, Emilien Macchi wrote:

It comes up some people are interested to help with Puppet OpenStack CI
work, so here is an etherpad:

https://etherpad.openstack.org/p/puppet-openstack-CI

Before working on any task, please make sure to chat with us on IRC or
ML, and put your name in the etherpad.

Also, any new topics are really welcome, so do thoughts  suggestions.

Thanks,


Thanks for pointing this out, I plan to help with the AIO module.

---
Paul Belanger


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

[openstack-dev] [Infra] Meeting Tuesday July 14th at 19:00 UTC

2015-07-13 Thread Elizabeth K. Joseph

Hi everyone,

The OpenStack Infrastructure (Infra) team is having our next weekly
meeting on Tuesday July 14th, at 19:00 UTC in #openstack-meeting

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is
welcome to to add agenda items)

Everyone interested in infrastructure and process surrounding
automated testing and deployment is encouraged to attend.

In case you missed it or would like a refresher, the meeting minutes
and full log from our last meeting are available here:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-07-07-19.02.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-07-07-19.02.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-07-07-19.02.log.html

-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

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

Re: [openstack-dev] [glance] The sorry state of our spec process



On 7/3/15, 05:35, Kuvaja, Erno kuv...@hp.com wrote:

First of all, Thanks Flavio for bring this open to the daylight!

I agree. More of these discussions need to happen on the mailing list.

I have been really frustrated about the Glance spec process since the
beginning and as glance core tried to work around the limitations the
best I can. I'm not sure if the process is similar way broken on the
other projects, but I think after piloting the process in Glance for
couple of cycles we should take some action on it.

Few comments inline as that way they are easier to scope.

 -Original Message-
 From: Flavio Percoco [mailto:fla...@redhat.com]
 Sent: Wednesday, July 01, 2015 2:49 PM
 To: openstack-dev@lists.openstack.org
 Subject: [openstack-dev] [glance] The sorry state of our spec process
 
 Greetings,
 
 We're 1 week through L-2 (or is it 2?, I can't do time) and we, the
glance
 project, haven't even merged a single spec. Regardless of the reasons
 behind this situation and the fact that we've been indeed taking steps
to
 improve this situation, I think we should put this issue to an end.

This is really sad state to be in. We haven't approved a single spec by
the time other projects are already freezing their spec repos for L.

I agree we should also have at least a handful of specs already merged
along with some of the implementation patches for them. That said,
projects that are already freezing their spec repos tend to see many more
proposals for us.

 
 There are many issues we've faced in Glance:
 
 1. The glance-drivers team is too small [0] 2. Many specs have been
held back
 waiting for code [1] 3. Huge expectations from the spec and very low
review
 rate (even from other members of the glance team).

This issue was discussed while ago and was postponed to clarify the
Glance Spec process. After that this is first initiative to bring the
issue back to table and I'd like to hear if that process defining work is
still blocking the expansion to share the workload. If so, could we
please get the proposal of that workload or at least the parts of it that
needs to be ironed out open in public so we can move that forward as
community?

So I think I agree with the movement other projects have been taking of
accepting a spec before the code is completed and reviewed and then moving
it to a list of completed specs once the code has been reviewed, merged,
etc.

 
 There was a recent discussion on this m-l[2] about the spec process in
Nova
 and while I don't agree with everything that was said there, I do think
it
 highlights important problems that we're facing in glance as well.
 
 Therefore, I'd like to propose the following:
 
 1. Expand our drivers team. I thik people in the glance community are
getting
 annoyed of reading this requests from me and The Mythical Man-Month
 would agree with them. However, it's really sad that some of our oldest
(in
 terms of tenure) contributors that have shown interest in joining the
team
 haven't been added yet. I proposed to bring all cores to the drivers
team
 already and I still think that's a good thing. Assuming that's
something we
 don't want, then I'd like us to find 2 or 3 people willing to volunteer
for this
 task.

If this still cannot happen I'd like to get full commitment from our
current drivers to dedicate the time and effort for speedy workflow on
our specs or step down and trash the whole spec process.

So the trick with this is the following:

1. For the drivers team we need people who know glance well as both a
product and a codebase and have a clear idea of how both need to move
forward.
2. For the drivers team we need people who can also see the architectural
implications of specs in review.
(other things I'm probably forgetting).

It's hard to pick two or three people to just join the team in that case.

 
 2. Lets try to get things into the backlog instead of expecting them to
be
 perfectly shaped and targeted for this release. Lets let people start
from  a
 base, generally agreed, idea so that code can be written and reviews on
the
 actual feature can be made. Once the feature is implemented, we can move
 the spec to the release directory. I believe this was also proposed in
Nikola's
 thread[2].

I'm huge supporter of this. Specs being part of our normal review
workflow makes changing them as needed easy and trackable. Why in earth
we need to have perfect plan and implementation for that plan before
we're willing to indicate approval for the initial idea?
 
 3. Not all specs need to have 3-month-long discussions to be approved.
 I'm not suggesting to just merge specs that are in poor state but we
can't
 always ask for code to understand whether a spec makes sense or not.
 
 Unfortunately, we're already in L-2 and I believe it'll be really hard
for some
 of those features to land in Liberty, which is also sad and quite a
waste of
 time.

How long we will have people trying to improve the project if any given
proposed functionality takes

Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master

2015-07-13 Thread Doug Hellmann

Excerpts from Matt Riedemann's message of 2015-07-13 08:52:37 -0500:
 
 On 7/13/2015 6:57 AM, Jeremy Stanley wrote:
  On 2015-07-13 10:08:16 +0200 (+0200), Ihar Hrachyshka wrote:
  clients and oslo libraries still maintain their py26 for a reason:
  decision to drop py26 was for server projects only.
 
  Yes, that decision was made at a time when our server projects had
  stable branches, but our clients and shared libraries did not. My
  recollection is that server projects only was a proxy for only
  projects with stable branches. Now that we have stable branches of,
  say, python-novaclient where we can backport juno-relevant security
  fixes, people on 2.6-only platforms who want to install and run
  python-novaclient from PyPI can use the stable/juno version (though
  I'll admit that finding which version works with 2.6 may be a tricky
  proposition for a consumer who is unaware of this situation).
 
 
 Taking python-novaclient as an example, there is still a gating py26 job 
 on that project, so it still works.
 
 If/when we drop py26 support for a client, we could tag that commit and 
 then people wanting to use the client on py26 could build a package from 
 before that tag and then lay down whatever other patches they needed.
 
 Tempest is already sort of doing some things like this with tagging 
 milestones due to the branchless nature of Tempest, so it seems the same 
 idea could be carried over to the clients in cases like this.

We'll want to tag final compatible releases before removing the job, and
then after that add a patch removing the trove classifier. The next
release after removing the trove classifier should increment the major
version number, indicating a drop in expected compatibility.

Doug

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

[openstack-dev] [nova] cross-site console web socket proxies no longer work

2015-07-13 Thread Mike Dorman

I noticed in Kilo there’s a validation check in the console web socket proxies 
to ensure the hostnames from the Origin and Host headers match.  This was as a 
result of CVE-2015-0259 (https://bugs.launchpad.net/nova/+bug/1409142).  
Effectively it disabled cross-site web socket connections.

This is OK for Horizon, but we also run our own custom UI that’s on a different 
hostname from the console proxy servers.  Therefore we need to have the 
cross-site connections work.  I have opened 
https://bugs.launchpad.net/nova/+bug/1474079 for this.

My thought is to add a new nova configuration parameter which would list 
additional allowed Origin hosts for the proxy servers.  And add those to the 
check at 
https://github.com/openstack/nova/blob/master/nova/console/websocketproxy.py#L116

I will probably go ahead and implement that for us internally, but interested 
in opinions on this approach for upstream Nova purposes.  I’m happy to do the 
work, but want to make sure this is generally in line with what the community 
would accept first.

Thanks,
Mike

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

Re: [openstack-dev] [Cinder] python-cinderclient functional tests

2015-07-13 Thread Matthew Treinish

On Mon, Jul 13, 2015 at 12:04:05PM -0700, Mike Perez wrote:
 On 16:28 Jul 10, Ivan Kolodyazhny wrote:
  Hi Mike,
  
  Unfortunately, we don't get a lot of stats [1] because we don't run it
  often. I've added 'check experimental' comment to latest
  python-cinderclient review request to get more stats.
  
  Review request to make this voting: https://review.openstack.org/#/c/200522/
  
  [1]
  http://graphite.openstack.org/render/?width=877height=548_salt=1436533755.887from=00%3A00_20150524until=23%3A59_20150710target=stats.zuul.pipeline.experimental.job.check-cinderclient-dsvm-functional.FAILUREtarget=stats.zuul.pipeline.experimental.job.check-cinderclient-dsvm-functional.SUCCESStarget=stats.zuul.pipeline.experimental.openstack.python-cinderclient.total_changestitle=check-cinderclient-dsvm-functional
 
 Add an agenda item to the next Cinder meeting. Sure there should be no
 objections.
 

Just an FYI that these tests used to always be voting until they were removed
from tempest. [1][2] Almost every other project that did the same client test
migration from tempest just made the new client specific jobs voting from the
start so there was no loss in coverage. I'm not entirely sure why cinderclient
got stuck as experimental jobs, but it doesn't seem overly contentious to me
to just flip the switch.

-Matt Treinish

[1] https://review.openstack.org/#/c/178757/
[2] http://lists.openstack.org/pipermail/openstack-dev/2015-April/063018.html


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

[openstack-dev] [ceilometer][neutron] question about ceilometer/network/statistics

2015-07-13 Thread Syd (Sydney) Logan

I'm trying to get my arms around how to develop ceilometer support for 
networking related data/counters. Seems like there might be a couple of ways to 
go about this.

On the one hand, there are the OpenDaylight and opencontrail contributions in 
https://github.com/openstack/ceilometer/tree/master/ceilometer/network/statistics

There is also the more general notification base class that is discussed 
somewhat heavily in the ceilometer documentation and in various presentations, 
and represented by the code here: 
https://github.com/openstack/ceilometer/blob/master/ceilometer/network/notifications.py

There is a third method, polling, that I will ignore as ceilometer seems to 
disapprove of its use (notifications to the OSLO bus are preferred).

Neutron seems to have fairly simple, billing-related counters implemented in 
NetworkNotificationBase 
(https://github.com/openstack/ceilometer/blob/master/ceilometer/network/notifications.py,
 currently around line 39).

In 
https://github.com/openstack/ceilometer/tree/master/ceilometer/network/statistics
 there are a few python files (e.g., flow.py) that define various counters.

The OpenDaylight and opencontrail contributions use very little of these (e.g., 
nothing from flow.py) - they just publish some basic SNMP-ish data like 
received and sent packets.

So, let's say I have network statistics. How do I approach the problem of 
integrating them with ceilometer?

1) Do I write my own agent and push whatever I want to OSLO bus, ignoring 
https://github.com/openstack/ceilometer/blob/master/ceilometer/network/notifications.py
 and what is in  
https://github.com/openstack/ceilometer/tree/master/ceilometer/network/statistics
 ?

or

2) Do I use only what is in 
https://github.com/openstack/ceilometer/tree/master/ceilometer/network/statistics
 (e.g., the counters in flow.py, port.py, switch.py, table.py) and write a 
driver?

If 2), am I expected to add new python files if something I have to publish to 
ceilometer is not represented by the counters that are already defined?

I believe both opendaylight and opencontrail have ml2 plugins - is this the 
reason for having ceilometer/network/statistics and driver.py interface? I 
realize in some sense these are different than say, Cisco nexus in that they 
are platforms, not switches. Is being a platform with a Neutron plugin the 
criteria for using driver.py and being located in ceilometer/network/statistics?

How does a Nexus plugin write to ceilometer, if it does? Do they have code that 
they supply customers or partners that supports ceilometer that fits one of 
these models but is not checked into openstack git repos?

Thanks,

syd

Syd Logan
Principal Engineer
Network Switching Software
Broadcom Corporation
Direct: 858-521-5101
Cell: 858-432-8597

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

[openstack-dev] [puppet] new etherpad to track Puppet OpenStack CI work

It comes up some people are interested to help with Puppet OpenStack CI
work, so here is an etherpad:

https://etherpad.openstack.org/p/puppet-openstack-CI

Before working on any task, please make sure to chat with us on IRC or
ML, and put your name in the etherpad.

Also, any new topics are really welcome, so do thoughts  suggestions.

Thanks,
-- 
Emilien Macchi



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

Re: [openstack-dev] [keystone] Liberty SFE Request - Dynamic Policies

2015-07-13 Thread Yee, Guang

++!

Per my understanding, the work, and therefore the risks, are fairly 
compartmentalized. The upside is this will pave the way for a much richer 
authorization management system.


Guang

From: Adam Young [mailto:ayo...@redhat.com]
Sent: Monday, July 13, 2015 10:15 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [keystone] Liberty SFE Request - Dynamic Policies

On 07/03/2015 08:36 AM, Samuel de Medeiros Queiroz wrote:
Hi Thierry,

Thanks for clarifying. A Spec Freeze Exception is what I was supposed to ask 
for.

Rectifying:

On behalf of the team working on the Dynamic Policies subject, I would like to 
ask for a *Spec Freeze Exception* in Liberty for it.

This one is an important lead in to a lot of other work. Getting just this in 
to Liberty allows us to focus the remainder of the work on Dynamic policy 
inside Keystone.

Please approve.




Thanks,
Samuel de Medeiros Queiroz

Thierry Carrez wrote:

samuel wrote:

[...]

On behalf of the team working on the Dynamic Policies subject, I would

like to ask for a Feature Freeze Exception in Liberty for it.

Liberty Feature Freeze is on September 3rd, so I doubt you need a

feature freeze exception at this time. I suspect that would be a spec

freeze exception or some other Keystone-specific freeze exception ?



https://wiki.openstack.org/wiki/FeatureFreeze







__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribemailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [keystone] No IRC Meeting Tuesday July 14

2015-07-13 Thread Morgan Fainberg

July 14 IRC Meeting is cancelled due to proximity to the Keystone MidCycle
(Wed, Thurs, and Fri) of this week. Meetings will resume normal schedule as
of July 21.

See everyone either at the MidCycle or at the next IRC meeting.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Magnum] Magnum Quick-Start: Need clarification on Kubernetes/Redis example

2015-07-13 Thread Dane Leblanc (leblancd)

Does anyone have recent experience getting the Kubernetes/Redis example to work 
in the Magnum developer Quick-Start guide?:

https://github.com/openstack/magnum/blob/master/doc/source/dev/dev-quickstart.rst#exercising-the-services-using-devstack

I can get everything in the Kubernetes/Redis example to work except for the 
last step. Here's what the quick-start guide says for this step:
Now log into one of the other container hosts and access a redis slave from 
there:
ssh minion@$(nova list | grep 10.0.0.4 | awk '{print $13}')
REDIS_ID=$(docker ps | grep redis:v1 | grep k8s_redis | tail -n +2 | awk 
'{print $1}')
docker exec -i -t $REDIS_ID redis-cli

127.0.0.1:6379 get replication:test
true
^D

exit

There are four redis instances, one master and three slaves, running across the 
bay, replicating data between one another.

What I'm seeing is a bit different:

(1)I have to use 'sudo docker' instead of 'docker'.  (No big deal.)

(2)I see one master redis instance on one minion and one slave redis 
instance on a second minion (each has its own associated sentinel container as 
expected).

(3)The redis-cli command times out with Could not connect to Redis at 
127.0.0.1:6379: Connection refused. HOWEVER, if I add a host IP and port for 
the redis master minion (-h 10.100.84.2 -p 6379), the example works.

Here is the failing case, without the host/port arguments:

[minion@k8-4gmqfvntvm-0-6fymzzw3wrjx-kube-minion-zjdejo5sffxv ~]$ 
REDIS_ID=$(sudo docker ps | grep redis:v1 | grep k8s_redis | awk '{print $1}')
[minion@k8-4gmqfvntvm-0-6fymzzw3wrjx-kube-minion-zjdejo5sffxv ~]$ sudo docker 
exec -i -t $REDIS_ID redis-cli
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected [minion@k8-4gmqfvntvm-0-6fymzzw3wrjx-kube-minion-zjdejo5sffxv ~]$

And here is the working case, using -h 10.100.84.2 -p 6379:

[minion@k8-4gmqfvntvm-0-6fymzzw3wrjx-kube-minion-zjdejo5sffxv ~]$ 
REDIS_ID=$(sudo docker ps | grep redis:v1 | grep k8s_redis | awk '{print $1}')
[minion@k8-4gmqfvntvm-0-6fymzzw3wrjx-kube-minion-zjdejo5sffxv ~]$ sudo docker 
exec -i -t $REDIS_ID redis-cli -h 10.100.84.2 -p 6379
10.100.84.2:6379 get replication:test
true
10.100.84.2:6379

Note that I determined the '10.100.84.2' address for the redis master by 
running the following on the master minion:

[minion@k8-4gmqfvntvm-1-6pnrx2hnxa3d-kube-minion-bh6nynhayhfy ~]$ sudo docker 
exec -i -t $REDIS_ID ip addr show dev eth0
5: eth0: BROADCAST,UP,LOWER_UP mtu 1472 qdisc noqueue state UP
link/ether 02:42:0a:64:54:02 brd ff:ff:ff:ff:ff:ff
inet 10.100.84.2/24 scope global eth0
   valid_lft forever preferred_lft forever
inet6 fe80::42:aff:fe64:5402/64 scope link
   valid_lft forever preferred_lft forever
[minion@k8-4gmqfvntvm-1-6pnrx2hnxa3d-kube-minion-bh6nynhayhfy ~]$

So I'm looking for confirmation as to whether or not using the -h 10.100.84.2 
-p 6379 arguments is the right way to test this configuration? Is this a 
successful test?

Thanks,
Dane

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

Re: [openstack-dev] [Neutron] New Neutron subproject for a Neutron backed Docker remote networking driver

2015-07-13 Thread Antoni Segura Puimedon

On Fri, Jul 10, 2015 at 5:34 PM, Gurucharan Shetty shet...@nicira.com wrote:
 On Fri, Jul 10, 2015 at 8:16 AM, Gurucharan Shetty shet...@nicira.com wrote:
 From a 2 min look, this seems to wrap docker commands instead of using
 the new plugin
 The plugin is here:
 https://github.com/shettyg/ovn-docker/blob/master/ovn-docker-overlay-driver



 I would very much welcome to join efforts so that we define a vendor 
 neutral,
 Neutron based generic container that provides the container Network plumbing
 using the plugin framework.
 Please continue with what you were doing. If you would like, you can
 use the above plugin driver as a starting point.
 I am not familiar with OpenStack sub-project development.  I am happy
 to contribute OVN specific code to the generic plugin system that you
 have in mind.


That would be great :-)

Thanks Gurucharan!

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

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

[openstack-dev] [mistral] Team meeting minutes/log - 07/13/2015

2015-07-13 Thread Renat Akhmerov

Thanks for joining us today and making a good meeting!

As usually,

Meeting minutes: 
http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-07-13-16.00.html
 
http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-07-13-16.00.html
Meeting log: 
http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-07-13-16.00.log.html
 
http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-07-13-16.00.log.html

The next meeting will be on July 20. Post your agenda items at 
https://wiki.openstack.org/wiki/Meetings/MistralAgenda 
https://wiki.openstack.org/wiki/Meetings/MistralAgenda

Renat Akhmerov
@ Mirantis Inc.



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

Re: [openstack-dev] [neutron][lbaas] Horizon support for neutron-lbaas v2

2015-07-13 Thread Jain, Vivek

Hi German,

We integrated UI with LBaaS v2 GET APIs. We have created all panels for
CREATE and UPDATE as well.
Plan is to share our code with community on stackforge for more
collaboration from the community.

So far Ganesh from cisco has shown interest in helping with some work. It
will be great if we can get more hands.

Q: what is the process for hosting in-progress project on stackforge? Can
someone help me here?

Thanks,
Vivek

On 7/10/15, 11:40 AM, Eichberger, German german.eichber...@hp.com
wrote:

Hi Vivek,

Hope things are well. With the Midccyle next week I am wondering if you
made any progress and/or how we can best help with the panels.

Thanks,
German

From: Jain, Vivek vivekj...@ebay.commailto:vivekj...@ebay.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.or
g
Date: Wednesday, April 8, 2015 at 3:32 PM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.or
g
Cc: Balle Balle, Susanne
susanne.ba...@hp.commailto:susanne.ba...@hp.com, Tonse, Milan
mto...@ebay.commailto:mto...@ebay.com
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
neutron-lbaas v2

Thanks German for the etherpad link. If you have any documentation for
flows, please share those too.

I will work with my team at ebay to publish wireframes for design we are
working on. It will be mostly along the lines I demo’ed in Paris.

Thanks,
Vivek

From: Eichberger, German
german.eichber...@hp.commailto:german.eichber...@hp.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.or
g
Date: Wednesday, April 8, 2015 at 11:24 AM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.or
g
Cc: Balle, Susanne susanne.ba...@hp.commailto:susanne.ba...@hp.com
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
neutron-lbaas v2

Hi,

We briefly talked about it a few Neutron meetings back (LBaaS is now on
demand) and created an etherpad to track things:
https://etherpad.openstack.org/p/LBaaS_Horizon_Use_Cases

Susanne and I met with HP’s UX designer to work on the design for some
flows for the Horizon panel (cc’d) but I am glad that Vivek is taking the
lead. Please check that etherpad for more information and feel free to
update as things happen…

Thanks,
German


From: Jain, Vivek [mailto:vivekj...@ebay.com]
Sent: Tuesday, April 07, 2015 9:01 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
neutron-lbaas v2

Hi Evgeny,
We have just started working on Horizon lbaasv2 support. I have to sync
up with my team on the time-line but it is not targeted for Kilo release.
Since it is a major effort, we will need more hands. Let me know if
anyone is interested to contribute.

On a related note, Do we have a sample code which uses neutronclient
lbaas v2 methods? That will greatly speedup our horizon integration.

Thanks,
Vivek

From: Phillip Toohill
phillip.tooh...@rackspace.commailto:phillip.tooh...@rackspace.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.or
g
Date: Tuesday, April 7, 2015 at 7:50 AM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-...@lists.openstack.or
g
Subject: Re: [openstack-dev] [neutron][lbaas] Horizon support for
neutron-lbaas v2


Hey Evgeny,



I believe Vivek is working on Horizon lbaasv2 support. We werent given a
timeline or anything but sounds like its being actively worked on. I
would reach out to him to get better timelines if concerned.


Phillip V. Toohill III
Software Developer
[http://600a2794aa4ab5bae6bd-8d3014ab8e4d12d3346853d589a26319.r53.cf1.rack
cdn.com/signatures/images/rackspace_logo.png]
phone: 210-312-4366
mobile: 210-440-8374


From: Evgeny Fedoruk evge...@radware.commailto:evge...@radware.com
Sent: Tuesday, April 7, 2015 5:50 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][lbaas] Horizon support for
neutron-lbaas v2

Hi guys,

LBaaS v2 has no horizon support as for now and I want to know if this
work is planned to be done and , if yes, in what time frame.
Is there a plan to develop it for Kilo or for L release?

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

Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master

2015-07-13 Thread Robert Collins

On 14 July 2015 at 02:10, Jeremy Stanley fu...@yuggoth.org wrote:
 On 2015-07-13 09:39:36 -0400 (-0400), Doug Hellmann wrote:
 [...]
 On the other hand, how much longer will we be supporting Juno? A
 matter of months, right?

 The reason it's being brought up again at this point is to ask
 whether it's more important that we keep master clients/libs working
 with 2.6 for several more months, or be able to push forward with
 our constraints overhaul between now and then. I'll be hard to have
 the necessary tooling in place before the liberty release if we
 can't actually use it before then (since that's roughly when juno
 EOL is scheduled).

Additional detail:
 - generating 2.6 pins for global requirements requires access to 2.6
where the periodic job runs *and where devs are generating updates*.
 - so that means docker or lxc or something in both the CI system and
widely available for devs.

So its a non-trivial impact; we can do it to move things forward, but
it would be a lot cheaper not to.

-Rob


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

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

Re: [openstack-dev] [puppet] running tempest on beaker jobs

2015-07-13 Thread Matthew Treinish

On Mon, Jul 13, 2015 at 07:50:59AM -0400, Emilien Macchi wrote:
 
 
 On 07/12/2015 11:29 PM, Matt Fischer wrote:
  We used Tempest for a time against our production environment. It was a
  pain to clean up but ephemeral test jobs solves that for you. A few
  questions: 
  
  What version of tempest will be using?
 
 master for now. We will see if new tags are created later.
 AFIK, tags mean Tempest does not support an old version of OpenStack
 (ie, tempest 5 only support juno / kilo / current (liberty)).

We push a tempest tag for basically 3 reasons:

1. Support for a new release, for example tempest-4 was used to mark the start
of supporting the kilo release (we pushed it at the ~kilo release) prior to this
point in the git history it wasn't guaranteed that tempest will work with kilo

2. The EOL of a stable branch support. This is what tempest-5 indicates, that
after the tag tempest isn't testing against icehouse code so it may or may
not work.

3. A major milestone in tempest development. An example for this one is
tempest-3 which we used to mark the removal of all the xml tests from tempest.

 
  Will we maintain a blacklist if there are known failures? (although this
  is a pain to keep updated)
 
 I don't think we'll have to, since tempest already provide some Python
 decorators to skip some bugs. If that happens, yes we'll have to find a
 way to exclude some tests or disable the run at all. That's why having
 it running without affecting job return code does not break anything now.

Honestly, you should be really reluctant to skip tests, and it should only be a
last resort. As for the skip decorators that's really only useful for skipping
from inside tempest. We use a skip decorator if there is a bug with a failure
rate is sufficiently high that it's blocking anything from landing and the cause
is unknown or the fix is far enough away that we need a faster way around. But
this is not normal operating procedure as is only done in very specific cases.

That being said, if you really need to do this the only selection logic you
have through testr is to leverage a regex to exclude tests.

-Matt Treinish


 
  On Sun, Jul 12, 2015 at 8:44 PM, Emilien Macchi
  emilien.mac...@gmail.com mailto:emilien.mac...@gmail.com wrote:
  
  Hi,
  
  I would like to propose to run Tempest at the end of the beaker
  jobs, for testing purpose now.
  
  As a start, we would accept 0  1 as return code, because this is
  really experimental.
  Though I think it will be interesting to see how it behaves,
  specially when we implement new configurations or plugins in our
  modules.
  
  I already did a PoC for puppet-keystone:
  https://review.openstack.org/198561
  (failing because it needs more work to pass keystone v3 tests but v2
  tests are successful).
  As you can see the code is really light, since we use puppet-tempest.
  
  Any suggestion is welcome !
  
  -- 
  Emilien Macchi
  
  
  __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe:
  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
  
  
  
  __
  OpenStack Development Mailing List (not for usage questions)
  Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
  
 
 -- 
 Emilien Macchi
 


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

[openstack-dev] [tags] ops:ha tag request for feedback

2015-07-13 Thread Maish Saidel-Keesing

I would appreciate if you could all leave your comments and thoughts on 
the following patch [1].


Please be advised this is an initial version and your feedback is very 
much appreciated.


[1] https://review.openstack.org/#/c/200128/1
--
Best Regards,
Maish Saidel-Keesing

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

[openstack-dev] [stackforge][deb][packges] Upstream repositories for OpenStack deb “server” packages

2015-07-13 Thread Igor Yozhikov

Hello everyone.

 During the Liberty summit in Vancouver, the idea to maintain OpenStack
packages for Debian and Ubuntu on upstream infra sparked. As part of the
Openstack and Debian community we still want to push for it. Instead of
trying to directly go for the /openstack namespace, we currently want to
start with smaller baby steps, using Stackforge. Mostly, it is server
packages for Debian which we want to see maintained there. All of the
dependencies (including Oslo libraries and python-*client) will continue to
be maintained using git.debian.org, as a shared effort between Debian and
Ubuntu.

Purpose:

   -

   One centralized place at stackforge to maintain package build
   manifests/specs for main OpenStack projects.
   -

   Stackforge already has gerrit where could be attached additional gates
   for building and testing OpenStack packages for deb based Linux
   distributions.
   -

   All changes related to the ways of how one or another OpenStack project
   should be installed would be represented or proposed to one place. So not
   only famous package maintainers can work on build manifests for packages,
   but also the entire community interested in packaging of OpenStack
   projects. Also this place could become as main base for packages for all
   deb based Linux distributions like Debian and Ubuntu.
   -

   Package build manifests could be reviewed or adjusted not only by
   package maintainers, but also by python developers, that are writing
   OpenStack code and that's could be very valuable due to possible changes in
   configuration, paths and so on.


Projects list:

Here I propose list of OpenStack projects, it consists of about 25 of
projects which of course would be changed with time due to possible birth
of new projects .

Project name

Possible stackforge repository

ceilometer

http://github.com/stackforge/deb-ceilometer

ceilometermiddleware

http://github.com/stackforge/deb-ceilometermiddleware

cinder

http://github.com/stackforge/deb-cinder

glance

http://github.com/stackforge/deb-glance

glance_store

http://github.com/stackforge/deb-glance_store

heat

http://github.com/stackforge/deb-heat

horizon

http://github.com/stackforge/deb-horizon

ironic

http://github.com/stackforge/deb-ironic

keystone

http://github.com/stackforge/deb-keystone

keystonemiddleware

http://github.com/stackforge/deb-keystonemiddleware

mistral

http://github.com/stackforge/deb-mistral

mistral-dashboard

http://github.com/stackforge/deb-mistral-dashboard

murano

http://github.com/stackforge/deb-murano

murano-dashboard

http://github.com/stackforge/deb-murano-dashboard

neutron

http://github.com/stackforge/deb-neutron

neutron-fwaas

http://github.com/stackforge/deb-neutron-fwaas

neutron-lbaas

http://github.com/stackforge/deb-neutron-lbaas

neutron-vpnaas

http://github.com/stackforge/deb-neutron-vpnaas

nova

http://github.com/stackforge/deb-nova

rally

http://github.com/stackforge/deb-rally

sahara

http://github.com/stackforge/deb-sahara

sahara-dashboard

http://github.com/stackforge/deb-sahara-dashboard

swift

http://github.com/stackforge/deb-swift

tempest

http://github.com/stackforge/deb-tempest

trove

http://github.com/stackforge/deb-trove



Thanks,
Igor Yozhikov
Senior Deployment Engineer
at Mirantis http://www.mirantis.com
skype: igor.yozhikov
cellular: +7 901 5331200
slack: iyozhikov
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Setting epoch in setup.cfg??

2015-07-13 Thread Dave Walker

On 13 Jul 2015 8:52 pm, Ian Cordasco ian.corda...@rackspace.com wrote:
 On 7/13/15, 03:38, Thierry Carrez thie...@openstack.org wrote:
SNIP
 By counter-productive, I meant: likely to generate more confusion than
 clarity. If you provide an epoch in the version and it doesn't match
 downstream packagers ones, it's hard to rely on it.

 I see what you mean now. The thing is that for Debian/Fedora the epoch
 syntax is different from PEP 440

 For them it's

 [distro-epoch]:[upstream-version][otherstuff]

 PEP 440 epochs are separated by a !, so let's say $(distro) has an epoch
 value of 1 and we choose 2, for glance the version would look ugly but
 would be:

 1:2!11.0.0

SNIP

This would be a problem for at least Ubuntu and Debian as the version
string is specifically not allowed to contain a '!'.

The upstream_version may contain only alphanumerics and the
characters . +- : ~ (full stop, plus, hyphen, colon, tilde) and should
start with a digit. [0]

Therefore, these distro's would need to increment the distro epoch if the
upstream version (without the upstream epoch) is lower than the version
currently in their archives.

I am not sure how rpm based distro's handle '!' in the upstream version.

[0]
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

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

Re: [openstack-dev] [neutron] Adding results to extension callbacks

2015-07-13 Thread Kevin Benton

This sounds like a lot of overlap with the dict extend functions. Why
weren't they adequate for the QoS use case?

On Mon, Jul 13, 2015 at 7:58 AM, Mike Kolesnik mkole...@redhat.com wrote:

 Hi,

 I sent a simple patch to check the possibility to add results to callbacks:
 https://review.openstack.org/#/c/201127/

 This will allow us to decouple the callback logic from the ML2 plugin in
 the QoS scenario where we need to update the agents in case the profile_id
 on a port/network changes.
 It will also allow for a cleaner way to extend resource attributes as
 AFTER_READ callbacks can return a dict of fields to add to the original
 resource instead of mutating it directly.

 Please let me know what you think of this idea.

 Regards,
 Mike


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




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

Re: [openstack-dev] [neutron][upgrades] Potential issues when performing Neutron upgrades

2015-07-13 Thread Kevin Benton

Thanks for the info. So the equivalent in neutron would be if we just
ensure backward compatible AMQP APIs, right?

On Mon, Jul 13, 2015 at 7:33 AM, Russell Bryant rbry...@redhat.com wrote:

 On 07/13/2015 04:09 AM, Kevin Benton wrote:
 because you won't have to run Neutron agents on compute nodes anymore.
 
  How will upgrades work for OVN?

 We haven't written anything down yet, but here's what I expect.

 Right now we're still changing the db schema however is needed without
 messing with versioning.  As we get to production ready, I expect
 we'll start being strict about only making backwards compatible ovsdb
 schema changes to make upgrades easier.

 There are 2 central components - ovn-northd and ovsdb-server - that
 would be upgraded first, which I would expect to be done at the same
 time as upgrading your Neutron control plane.  As long as any ovsdb
 schema changes are backwards compatible, you could do rolling-upgrades
 of ovn-controller on compute or network nodes.

 --
 Russell Bryant

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




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

Re: [openstack-dev] [all] Setting epoch in setup.cfg??

2015-07-13 Thread Dave Walker

On 13 July 2015 at 21:58, Ian Cordasco ian.corda...@rackspace.com wrote:
 On 7/13/15, 15:09, Dave Walker em...@daviey.com wrote:
SNIP


Therefore, these distro's would need to increment the distro epoch if the
upstream version (without the upstream epoch) is lower than the version
currently in their archives.
I am not sure how rpm based distro's handle '!' in the upstream version.

 In other words, if Debian/Ubuntu currently have Glance versioned:

   1:2015.1.0

 They'll be doing

   2:8.0.0

 For Liberty?

They already are:
https://launchpad.net/ubuntu/+source/glance/2:11.0.0~b1-0ubuntu2

--
KInd Regards,
Dave Walker

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

Re: [openstack-dev] [all] Setting epoch in setup.cfg??



On 7/13/15, 03:38, Thierry Carrez thie...@openstack.org wrote:

Ian Cordasco wrote:
 On 7/10/15, 03:44, Thierry Carrez thie...@openstack.org wrote:
 Also you'll find that the various distros use different epoch values
for
 the same software, because epoch are also used to cover local blunders
 in packaging and historical artifacts. That is why epochs should be
 local to each packaging system and specifying it upstream is imho
 counter-productive.
 
 So, unpopular opinion time, but I think we restrict ourselves way too
much
 based on a false notion that the only people who consume OpenStack are
 consuming it via downstream packages. Joshua has pointed out a very real
 use case (deploying inside a virtual environment) and there are also
cases
 where people build from source and will be (attempting) to upgrade from
 2015.1.x to 11.0.0 or 8.0.0. Even if people only use PyPI as a way of
 determining version order, using epochs will be significantly better for
 them. Perhaps I'm too late to the discussion, but it also appears no
other
 opinions were solicited for it, especially not from users or operators.
 
 Specifically, I'd like to understand why using a feature of PEP 440 to
 explicitly indicate a shift in version numbering is
counter-productive.
 It seems like it would be very productive for people who aren't tightly
 integrated into the development process.

By counter-productive, I meant: likely to generate more confusion than
clarity. If you provide an epoch in the version and it doesn't match
downstream packagers ones, it's hard to rely on it.

I see what you mean now. The thing is that for Debian/Fedora the epoch
syntax is different from PEP 440

For them it's

[distro-epoch]:[upstream-version][otherstuff]

PEP 440 epochs are separated by a !, so let's say $(distro) has an epoch
value of 1 and we choose 2, for glance the version would look ugly but
would be:

1:2!11.0.0

That said, I can see your point: people who consume from pip would like
to have epochs too, epoch-sanitized versioning should not be reserved to
distros.

What I want to avoid is releasing nova-2!12.0.0.0.tar.gz tarballs,
because that would be ugly (and confusing, with distros all having their
own idea of an epoch set as well). But I don't mind including an epoch=
parameter in setup.cfg if that makes pip happier.

Could you detail what your preferred system would look like ?

-- 
Thierry Carrez (ttx)

So as Joshua already pointed out, epochs exist in PEP 440 for exactly our
situation. In fact, the PEP specifically calls out:

 For example, if a project is using date based versions like 2014.04 and
would like to switch to semantic versions like
 
 1.0, then the new releases would be identified as older than the date
based releases when using the normal sorting scheme


I also want to point out that epochs are not a one-and-done situation
before proposing what I'm about to propose. Once we start using them, for
the ordering to be as we intend, we have to continue using them.

So I know that some projects have been through more than one versioning
scheme already. For them, I think the epoch value should be: 2. For the
rest I would argue that the value should be 1.

For example, Nova's tags have 0.9.0 as the earliest tagged version and
2011.1 as the one after that. So Nova's version would be 2!12.0.0. Glance
has started with 2011.3 (to the best of my knowledge) so that would be
1!11.0.0.

I agree this probably might be confusing, so I'm fine with everything
using a single epoch value. (All using 1 or all using 2 or whatever we
choose.)

That said, I think we should keep our epoch values simple to keep them
standard (e.g., a numeric value, not something like nova-2). Further, I
think you're nudging towards epoch's being something that pbr adds to the
version when it's installed by pip. That seems reasonable, but I think we
will end up confusing people if they see 1!11.0.0 of Glance installed when
they used the 11.0.0 tag from Glance. Does that make sense? I think the
tags should include the epoch. Does anyone have a good reason for not
including the epoch in the tag?

Cheers,
Ian

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

Re: [openstack-dev] [neutron] Reading an updated port's fixed IPs in mech driver update_port_postcommit

2015-07-13 Thread Kevin Benton

Since this is post-commit, can you try using a new admin context for the
get_port call and see if it suffers from the same problem? So instead of
passing context._plugin_context, pass in ctx.get_admin_context().

On Fri, Jul 10, 2015 at 4:49 AM, Neil Jerram neil.jer...@metaswitch.com
wrote:

 Sorry to leave this unanswered.

 It happens every time (as far as we've tested so far).

 A pragmatic fix appears to be to explicitly requery the IPAllocation
 table, as you can see in the two commits here:

 https://github.com/Metaswitch/calico/commit/5512ce7dd50db414f161bddcef17b0846a1466ac

 https://github.com/Metaswitch/calico/commit/4ecaf3568af52ef9cc29662a3b94672540056f05

 But still it seems a shame if this is needed.

 Neil


 On 07/07/15 22:32, Kevin Benton wrote:

 How often does this happen? Is it on every call? If not, is it possible
 the forking logic in require_state is messing up the DB handle when it's
 invoked?

 One way to make sure there aren't open transactions for testing is to
 just remove the subtransactions=True statement from update_port in the
 ML2 plugin.

 On Jul 7, 2015 8:33 AM, Neil Jerram neil.jer...@metaswitch.com
 mailto:neil.jer...@metaswitch.com wrote:

 Thanks, Kevin, but I believe we're already doing what you advise;
 please see

 https://github.com/Metaswitch/calico/blob/master/calico/openstack/mech_calico.py#L346-348

 Is there a way of checking that there aren't still any open
 transactions, when update_port_postcommit is called?

 Thanks,
  Neil


 On 07/07/15 15:57, Kevin Benton wrote:

 It sounds like something is starting a transaction before calling
 update_port on the core plugin. This will prevent the
 transaction from
 being completely closed even though ML2 is in the post_commit
 phase.

 In your db.get_port call, make sure you are using the same DB
 session
 from the context that was passed into update_port_postcommit and
 that
 will make sure you always have access to the current state even
 if the
 transaction isn't closed.

 On Tue, Jul 7, 2015 at 5:35 AM, Neil Jerram
 neil.jer...@metaswitch.com mailto:neil.jer...@metaswitch.com
 mailto:neil.jer...@metaswitch.com

 mailto:neil.jer...@metaswitch.com wrote:

  I think there's something I'm not understanding about how
 Neutron's
  DB tables are related, and when one can safely read
  believed-to-be-committed information from them...

  My project's mechanism driver is handling a port update in
 which the
  fixed IPs are changing; specifically, a second fixed IP has
 been
  added to the port.  It does this (for a reason I can explain
 if
  needed) by calling db.get_port(), in the
 update_port_postcommit hook.

  But we observe that the result of db.get_port() does not
 include the
  new fixed IP.  Even though we're in the postcommit hook,
 and hence
  we assume that all the changes for that port have by now
 been committed.

  What are we misunderstanding here?  My guess is that this is
  something to do with 'fixed_ips' not being a column
 directly in the
  Ports table, but instead calculated from relationships
 between the
  port ID and another (IPAllocation) table.  We've seen a
 similar
  problem in the past with binding:host_id, for which the same
 is
  true, i.e. info is in the separate portbindings table.

  Or could it be that the transaction hasn't really been
 closed yet,
  when update_port_postcommit hook is called?

  (This is with Icehouse-level code, so it could be something
 that's
  been fixed...)

  Many thanks,
   Neil



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

 
 http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Kevin Benton



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

Re: [openstack-dev] [puppet] running tempest on beaker jobs

2015-07-13 Thread Matthew Treinish

On Sun, Jul 12, 2015 at 09:29:57PM -0600, Matt Fischer wrote:
 We used Tempest for a time against our production environment. It was a
 pain to clean up but ephemeral test jobs solves that for you. A few
 questions

Just curious how long ago was this? Because resource leaks have always been
treated as bugs in tempest. We've done a lot of work over the past year to get
better about our cleanup in tempest. There are also config options to limit the
dynamic creation of resources and provide a static set of user/tenants to
limit any potential dangling users. [1] Although we should always be calling
delete for created users and projects as part of test setup. (this had to be
fixed for other internal mechanisms to work)

I'm just looking to get more feedback about this, because I see statements like
this from time to time but not many bugs being filed about specific issues
people encounter.

 
 What version of tempest will be using?
 Will we maintain a blacklist if there are known failures? (although this is
 a pain to keep updated)

Do you mean because of configuration differences you don't want to run certain
tests or because of bugs in OpenStack causing intermittent failures?

-Matt Treinish

[1] 
http://docs.openstack.org/developer/tempest/configuration.html#locking-test-accounts-aka-accounts-yaml-or-accounts-file

 
 On Sun, Jul 12, 2015 at 8:44 PM, Emilien Macchi emilien.mac...@gmail.com
 wrote:
 
  Hi,
 
  I would like to propose to run Tempest at the end of the beaker jobs, for
  testing purpose now.
 
  As a start, we would accept 0  1 as return code, because this is really
  experimental.
  Though I think it will be interesting to see how it behaves, specially
  when we implement new configurations or plugins in our modules.
 
  I already did a PoC for puppet-keystone:
  https://review.openstack.org/198561
  (failing because it needs more work to pass keystone v3 tests but v2 tests
  are successful).
  As you can see the code is really light, since we use puppet-tempest.
 
  Any suggestion is welcome !
 
  --
  Emilien Macchi
 


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

Re: [openstack-dev] [puppet] running tempest on beaker jobs

2015-07-13 Thread Matt Fischer

My tempest experience is dated to Havana, so I'll consider it to be
completely out of date. Glad to he about all these improvements.
On Jul 13, 2015 2:12 PM, Matthew Treinish mtrein...@kortar.org wrote:

 On Sun, Jul 12, 2015 at 09:29:57PM -0600, Matt Fischer wrote:
  We used Tempest for a time against our production environment. It was a
  pain to clean up but ephemeral test jobs solves that for you. A few
  questions

 Just curious how long ago was this? Because resource leaks have always been
 treated as bugs in tempest. We've done a lot of work over the past year to
 get
 better about our cleanup in tempest. There are also config options to
 limit the
 dynamic creation of resources and provide a static set of user/tenants to
 limit any potential dangling users. [1] Although we should always be
 calling
 delete for created users and projects as part of test setup. (this had to
 be
 fixed for other internal mechanisms to work)

 I'm just looking to get more feedback about this, because I see statements
 like
 this from time to time but not many bugs being filed about specific issues
 people encounter.

 
  What version of tempest will be using?
  Will we maintain a blacklist if there are known failures? (although this
 is
  a pain to keep updated)

 Do you mean because of configuration differences you don't want to run
 certain
 tests or because of bugs in OpenStack causing intermittent failures?

 -Matt Treinish

 [1]
 http://docs.openstack.org/developer/tempest/configuration.html#locking-test-accounts-aka-accounts-yaml-or-accounts-file

 
  On Sun, Jul 12, 2015 at 8:44 PM, Emilien Macchi 
 emilien.mac...@gmail.com
  wrote:
 
   Hi,
  
   I would like to propose to run Tempest at the end of the beaker jobs,
 for
   testing purpose now.
  
   As a start, we would accept 0  1 as return code, because this is
 really
   experimental.
   Though I think it will be interesting to see how it behaves, specially
   when we implement new configurations or plugins in our modules.
  
   I already did a PoC for puppet-keystone:
   https://review.openstack.org/198561
   (failing because it needs more work to pass keystone v3 tests but v2
 tests
   are successful).
   As you can see the code is really light, since we use puppet-tempest.
  
   Any suggestion is welcome !
  
   --
   Emilien Macchi
  

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


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

[openstack-dev] [Magnum] [Networking]

2015-07-13 Thread Daneyon Hansen (danehans)


For those involved in Magnum networking, I suggest attending the upcoming 
Docker Meetup:

http://www.meetup.com/Docker-Online-Meetup/events/223796871/

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

Re: [openstack-dev] [all] Setting epoch in setup.cfg??