[openstack-dev] [Neutron][LBaaS] join

2016-01-04 Thread Sylvain, Lawrence J.
Thanks.

With highest regards,

Lawrence

Lawrence Sylvain
Zeta Associates
direct 571.732.4029
fax 703.272.1028
secure 856.2013
sylvain-lawre...@zai.com
10302 Eaton Place
Fairfax, Virginia 22030
www.zai.com


This message is intended only for the use of the individual or entity to which 
it is addressed and may contain ZETA Associates confidential or proprietary 
information. If you are not the intended recipient, any use, dissemination, or 
distribution of this communication is prohibited. If you have received this 
communication in error, please notify the sender and delete all copies.
__
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] [glance] Seeking FFE for "Add CIM namespace metadata definitions"

2016-01-04 Thread Bhandaru, Malini K
Hello Glance Team!

Hope you had a wonderful vacation and wishing you health and 
happiness for 2016.

Would very much appreciate your considering https://review.openstack.org/259694 
for a feature freeze exception.

Thank you to Travis Tripp for chiming in. Searchlight APIs will provide elastic 
search capability, and users such as Horizon can leverage these.

Supporting CIM namespace thus requires just importing the namespace tags and we 
already have a PoC implementation by Lin, which is how

we were able to generate the graphics in Horizon that were attached to the 
spec. Would appreciate core votes to approve this spec.



Regards

Malini

__
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 January 5th at 19:00 UTC

2016-01-04 Thread Elizabeth K. Joseph
Hi everyone,

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

Meeting agenda available here:
https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting

Anyone is welcome to to add agenda items and everyone interested in
the project 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 logs from our last meeting are available:

Minutes: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-12-29-19.02.html
Minutes (text):
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-12-29-19.02.txt
Log: 
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-12-29-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


[openstack-dev] [openstack][openstack-operators] Starting with Jenkins and jjb/OpenStack Board of Directors

2016-01-04 Thread JJ Asghar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hey everyone,

First off, I've looked around and there are some great tutorials on the
jjb and Jenkins. The problem I found was that there isn't a "lets start
from scratch" type tutorial.

I tried to fix this with this simple how-to[1]. Hopefully it's easy
enough to get someone who is gun shy with starting with the jjb to take
the leap.

Secondly, if you don't know, I'm running[2] for the OpenStack Board of
Directors as an Operator and attempt to represent the Operating
Community on the Board. I'm going to attempt to campaign using, the
mailing list, twitter, probably linkedin and the like. I'd love to get
your vote. So, please, if you have voting rights next week please
consider me.

If you would like to help me out tweets, or emails to colleagues are
probably the best way. More people posting and voting will help get the
buzz that we as a community needs.

Here's a example tweet if you'd like to copy and paste ;) :

I’m voting for that @jjasghar, he should be on the #OpenStack Board of
Directors! Read his reasons here: http://bit.ly/JJ-4-OpenStack-BoD-2016

Thanks for your time, and if you have any questions don't hesitate to
reach out.

[1]:
http://jjasghar.github.io/blog/2016/01/03/getting-jenkins-and-jenkins-job-builder-running/
[2]: http://bit.ly/JJ-4-OpenStack-BoD-2016


- -- 
Best Regards,
JJ Asghar
c: 512.619.0722 t: @jjasghar irc: j^2
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWitfkAAoJEDZbxzMH0+jT8m8P/A45LznC6FGktg0llm7SO4Pk
dsIRTIxi8HHjHegSzjlaeDK+G3wN+JcmrWLh0r5dVcnYf7VSHYtHKet7uBtCRko2
4wgvnZDWbNcyKu4bIpUTQuBCcoPowlVZiMXYiFUxAUvoV196O72aZVfj62UCRUNf
kbhG1JgOXMyOGiiB9zY41tuiu6UvnBJQkJ86VnbEJiVcThPAhRPpf6KgVgg/bi/h
b45ZHHCbXU7CJ1wx+qFOZznA1ntSzhF5SIflwUhJfAkC7IrFZYp6rvSltYgInbIN
KC1G2eS5AxU5cUrKacDf+07fpi30LmVDb3RmIu+WATJiSTb0ImGKupLYRyMVaUC6
FUBSyBuqSctX2ifYPAGKV3UmNaCfvO8I+LeEj6o+lkAO+C+5EGECJmTH30JyatsZ
Bs2eSvJjXxRdTQX5ztekPFV8q9uuoTX3+CLFQUfYU54iuG/9B4a/3GiiZm8A0vWE
nMRP2CER5HICn9WmDlygfuauPW80lyfZJe2BGAt+f2byg6e3cDNsHI9rJvKCKu6Y
vA+HBfOj/7BUA87ppfbzpzIfXPmQ3hg8xPZuliR071Nh7J/wh8WyerkVHaYt9Mu9
J1rf7wrEFw+9E0xrFZpXdxEAC7nklU5rRXa4fCX2OJTzdy8VTpIISfeXfEg5YX0K
rFHZ4sQO/rjOpggylG5u
=QqNc
-END PGP SIGNATURE-

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


Re: [openstack-dev] [heat] Client checking of server version

2016-01-04 Thread Clint Byrum
Excerpts from Jay Dobies's message of 2016-01-04 12:53:07 -0800:
> I ran into an issue in a review about moving environment resolution from 
> client to server [1]. It revolves around clients being able to access 
> older versions of servers (that's a pretty simplistic description; see 
> [2] for the spec).
> 
> Before the holiday, Steve Hardy and I were talking about the 
> complications involved. In my case, there's no good way to differentiate 
> an older server from a legitimate error.
> 
> Since the API isn't versioned to the extent that we can leverage that 
> value, I was looking into using the template versions call. Something 
> along the lines of:
> 
>supported_versions = hc.template_versions.list()
>version_nums = [i.to_dict()['version'].split('.')[1] for i in 
> supported_versions]
>mitaka_or_newer = [i for i in version_nums if i >= '2016-04-08']
> 
> Yes, I'm planning on cleaning that up before submitting it :)
> 
> What I'm wondering is if I should make this into some sort of 
> generalized utility method in the client, under the assumption that 
> we'll need this sort of check in the future for the same backward 
> compatibility requirements.
> 
> So a few questions:
> 
> 1. Does anyone strongly disagree to checking supported template versions 
> as a way of determining the specifics of the server API.
> 

I strongly disagree with anything that requires every clientn in every
language that wants to operate with older and newer services to have
the same clever knowledge implemented.

Try writing the REST documentation for it:

"If you want to do something with environments, query the template
portion of the API, and if you can use templates newer than 2016-04-18,
then you can use the new environments feature. Do not be confused by this,
it is totally unrelated to the template format you are using."

Sounds like it is time to micro-version Heat's API.

__
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] Nodepool and wiki.openstack.org downtime on 5 January 2016

2016-01-04 Thread Colleen Murphy
The site wiki.openstack.org as well as the nodepool service will be offline
for 30 minutes starting at 2100 UTC on 5 January 2016 while we update
infrastructure management of these services. The nodepool downtime will
cause a disruption in the testing infrastructure that will cause jobs to be
delayed.

If you have questions, please reply to this thread or contact us in
#openstack-infra.

Colleen
__
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][libvirt] Deprecating the live_migration_flag and block_migration_flag config options

2016-01-04 Thread Mark McLoughlin
Hi

commit 8ecf93e[1] got me thinking - the live_migration_flag config
option unnecessarily allows operators choose arbitrary behavior of the
migrateToURI() libvirt call, to the extent that we allow the operator
to configure a behavior that can result in data loss[1].

I see that danpb recently said something similar:

  https://review.openstack.org/171098

  "Honestly, I wish we'd just kill off  'live_migration_flag' and
  'block_migration_flag' as config options. We really should not be
  exposing low level libvirt API flags as admin tunable settings.

  Nova should really be in charge of picking the correct set of flags
  for the current libvirt version, and the operation it needs to
  perform. We might need to add other more sensible config options in
  their place [..]"

I've just proposed a series of patches, which boils down to the
following steps:

  1) Modify the approach taken in commit 8ecf93e so that instead of 
     just warning about unsafe use of NON_SHARED_INC, we fix up the 
     config option to a safe value.

       https://review.openstack.org/263431

  2) Hard-code the P2P flag for live and block migrations as 
     appropriate for the libvirt driver being used.

 For the qemu driver, We should always use VIR_MIGRATE_PEER2PEER 
     both live and block migrations. Without this option, you get:

   Live Migration failure: Requested operation is not valid: direct 
migration is not supported by the connection driver

 OTOH, the Xen driver does not support P2P, and only supports 
     "unmanaged direct connection".

       https://review.openstack.org/263432

  3) Require the use of the UNDEFINE_SOURCE flag, and the non-use of
 the PERSIST_DEST flag.

 Nova itself persists the domain configuration on the destination
 host, but it assumes the libvirt migration call removes it from
the
 source host. So it makes no sense to allow operators configure
 these flags.

   https://review.openstack.org/263433

  4) Add a new config option for tunneled versus native:

   [libvirt]
   live_migration_tunneled = true

 This enables the use of the VIR_MIGRATE_TUNNELLED flag. We have 
     historically defaulted to tunneled mode because it requires the 
     least configuration and is currently the only way to have a 
     secure migration channel.

     danpb's quote above continues with:

       "perhaps a "live_migration_secure_channel" to indicate that 
        migration must use encryption, which would imply use of 
        TUNNELLED flag"

     So we need to discuss whether the config option should express the
     choice of tunneled vs native, or whether it should express another
     choice which implies tunneled vs native.

       https://review.openstack.org/263434

  5) Add a new config option for additional migration flags:

   [libvirt]
   live_migration_extra_flags = VIR_MIGRATE_COMPRESSED

 This allows operators to continue to experiment with libvirt behaviors
 in safe ways without each use case having to be accounted for.

   https://review.openstack.org/263435

 We would disallow setting the following flags via this option:

   VIR_MIGRATE_LIVE
   VIR_MIGRATE_PEER2PEER
   VIR_MIGRATE_TUNNELLED
   VIR_MIGRATE_PERSIST_DEST
   VIR_MIGRATE_UNDEFINE_SOURCE
   VIR_MIGRATE_NON_SHARED_INC
   VIR_MIGRATE_NON_SHARED_DISK

which would allow the following currently available flags to be set:

   VIR_MIGRATE_PAUSED
   VIR_MIGRATE_CHANGE_PROTECTION
   VIR_MIGRATE_UNSAFE
   VIR_MIGRATE_OFFLINE
   VIR_MIGRATE_COMPRESSED
   VIR_MIGRATE_ABORT_ON_ERROR
   VIR_MIGRATE_AUTO_CONVERGE
   VIR_MIGRATE_RDMA_PIN_ALL

  6) Deprecate the existing live_migration_flag and block_migration_flag
 config options. Operators would be expected to migrate to using the
 live_migration_tunneled or live_migration_extra_flags config options.
 During the deprecation period we would invite feedback as to whether
 additional config options are needed to cover unanticipated use cases.

   https://review.openstack.org/263436


Thanks in advance for any feedback.

I'm going to guess that one piece of feedback will be that some subset
of this needs a blueprint (and maybe a spec), and that the blueprint
freeze was a month ago, so that subset needs to be punted until after
Mitaka? I'd love to be wrong about that, though :)

Thanks,
Mark.

[1] - https://review.openstack.org/228853
[2] - Data loss can occur when you have disk images on shared storage and 
you specify the VIR_MIGRATE_NON_SHARED_INC or VIR_MIGRATE_NON_SHARED_DISK 
because during the block migration the disk is copied back over itself
while it is in use from another node.

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

[openstack-dev] [heat] Client checking of server version

2016-01-04 Thread Jay Dobies
I ran into an issue in a review about moving environment resolution from 
client to server [1]. It revolves around clients being able to access 
older versions of servers (that's a pretty simplistic description; see 
[2] for the spec).


Before the holiday, Steve Hardy and I were talking about the 
complications involved. In my case, there's no good way to differentiate 
an older server from a legitimate error.


Since the API isn't versioned to the extent that we can leverage that 
value, I was looking into using the template versions call. Something 
along the lines of:


  supported_versions = hc.template_versions.list()
  version_nums = [i.to_dict()['version'].split('.')[1] for i in 
supported_versions]

  mitaka_or_newer = [i for i in version_nums if i >= '2016-04-08']

Yes, I'm planning on cleaning that up before submitting it :)

What I'm wondering is if I should make this into some sort of 
generalized utility method in the client, under the assumption that 
we'll need this sort of check in the future for the same backward 
compatibility requirements.


So a few questions:

1. Does anyone strongly disagree to checking supported template versions 
as a way of determining the specifics of the server API.


2. Does anything like this already exist that I can use?

3. If not, any suggestions on where I should put it? I see a 
heat.common.utils module but I'm not sure if there is a convention 
against that module (or common in general) making live server calls.


Thanks :D


[1] https://review.openstack.org/#/c/239504/
[2] https://review.openstack.org/#/c/226157/

__
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] notification subteam meeting

2016-01-04 Thread Balázs Gibizer
Hi, 

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

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

See you there.

Cheers,
Gibi

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

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


Re: [openstack-dev] Can I count on the OS-TRUST extension for a backup service?

2016-01-04 Thread Steven Hardy
On Fri, Dec 25, 2015 at 07:04:19PM -0800, Preston L. Bannister wrote:
>In the implementation of a instance backup service for OpenStack, on
>restore I need to (re)create the restored instance in the original tenant.
>Restores can be fired off by an administrator (not the original user), so
>at instance-create time I have two main choices:
> 1. Create the instance as the backup service.
> 2. Create the instance as the original user.
>Clearly (1) is workable (given the backup user has access to the tenant).
>Keypairs are a bit of an issue, but solvable.
>Also clearly (2) is better, but that requires a means to impersonate the
>original user. Keystone trusts seem to be that means, but raises
>additional questions. (Also the fact the current documentation for
>Keystone is incomplete in this area does not raise the confidence level.)
> 1. How far back is the Keystone OS-TRUST extension reliable? (Kilo?
>Juno?)

Heat first started using trusts in Havana, and although there were a few
bugs early in that process, IIRC things have been pretty much solid since
Icehouse.

https://blueprints.launchpad.net/heat/+spec/heat-trusts

> 2. Do any OpenStack distributions omit the OS-TRUST extension?
>A feature labelled as an "extension" poses a risk to the developer. :)

Trusts have long been enabled by default in keystone:

https://github.com/openstack/keystone/blob/master/etc/keystone.conf.sample#L2005

So, FWIW, my take on it is it's reasonable for other services to rely on
them being enabled by default - heat has used trusts by default since Kilo:

https://bugs.launchpad.net/heat/+bug/1286157

The mitigation for it being an extension in the Heat case, is we provide a
config option to switch back to the old pre-trusts behavior, but we default
to using trusts unless explicitly configured otherwise.

HTH,

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] [heat][telemetry] gate-ceilometer-dsvm-integration broken

2016-01-04 Thread Rabi Mishra
> On Mon, Dec 28, 2015 at 01:52:45PM +0100, Julien Danjou wrote:
> > On Mon, Dec 28 2015, Rabi Mishra wrote:
> > 
> > > Yes, this has started happening after keystone/trusts config changes by
> > > the
> > > devstack patch you mentioned. I've no idea how this can be fixed. As
> > > Steve
> > > Hardy is away, either someone with keystone knowledge should fix this or
> > > we
> > > merge the devstack patch revert[3] that I tested few days ago.
> > 
> > Why don't you just revert the devstack change?
> > 
> > This is way saner than disabling the test! Steve will be able to rework
> > his initial change when he come back.
> 
> Firstly, I'm very sorry for the breakage here, and I agree that in general
> a quick-revert is the best policy when something like this happens.
> 
> I'm a little unclear how this occurred tho, since I had a clear CI run on
> this patch:
> 
> https://review.openstack.org/#/c/256315/
> 
> Which had a Depends-On to the devstack change, anyone know why that didn't
> fail with the CeilometerAlarmTest.test_alarm before the devstack change
> merged?

It seems the test was skipped[1], as it was disabled for another bug[2].

[1] 
http://logs.openstack.org/15/256315/2/check/gate-heat-dsvm-functional-orig-mysql/bffccd5/console.html.gz#_2015-12-14_23_33_13_394
[2] https://bugs.launchpad.net/heat/+bug/1523337

> Regardless, we've got several fixes now which can be considered:
> 
> 1. Rabi's devstack revert:
> 
> https://review.openstack.org/#/c/261310/
> 
> 2. Fix the actual issue in heat:
> 
> https://review.openstack.org/#/q/topic:bug/1529058
> 
> Given that the review latency on Devstack is quite high, it seems possible
> we'll land (2) before (1) lands, but if not then I'll re-propose it and
> hopefully figure out where I went wrong with Depends-On to confirm all is
> fixed before it lands.
> 
> Also, there's this fix:
> 
> https://review.openstack.org/#/c/261398/
> 
> I've not yet confirmed if this also fixes the issue referencing the default
> domain which broke the alarm tests.
> 
> 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] [Horizon] Bug Day 2

2016-01-04 Thread Rob Cresswell (rcresswe)
Hi folks,

I think we should have another bug day to continue the good work started last 
time. I’d suggest Tuesday the 12th of January, as most people should be back at 
work by then. We can use the same etherpad too: 
https://etherpad.openstack.org/p/horizon-bug-day

For those not around for the previous one, the bug day is used to review our 
bug reports on Launchpad, and discuss them in IRC. This may be asking for help 
recreating an issue, whether a bug has been fixed etc. The goal is to have an 
organised, prioritised list of valid bug reports. Open new bugs if you stumble 
across them, but bug discovery is not the focus here.

Regards,
Rob




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


Re: [openstack-dev] [kolla] Adding Ubuntu Liberty to Kolla-Mitaka

2016-01-04 Thread Steven Dake (stdake)


On 1/4/16, 3:15 AM, "Thomas Goirand"  wrote:

>On 01/03/2016 10:45 PM, Sam Yaple wrote:
>> That said if you have a link to the project-config patch I will be more
>>than
>> happy to review it and follow it.
>
>My point being: I don't even know where to start. I need someone to help
>me start it, and then, I can fix/enhance/improve it.
>
>And yes, I did try, and read the docs. Any pointers would be helpful.
>
>Cheers,
>
>Thomas Goirand (zigo)
>

Thomas,

Adding a distribution to the gating is a very complex activity and
requires IIRC a full-time engineer to commit to maintaining the images.
Kolla developers can't help here, because we don¹t know how to add Debian
images to the gate.  Your best bet is to drop by #openstack-infra on irc
and ask the appropriate questions.  The infra team rocks and can get you
headed in the correct direction.  But keep in mind, it is a big commitment
to add a distro to the gating.

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


Re: [openstack-dev] [Horizon][Neutron] dashboard repository for neutron subprojects

2016-01-04 Thread Ihar Hrachyshka

Akihiro Motoki  wrote:


[Packaging perspective]

I am not sure how it affects.
There is one concern as a package consumer.

Getting additional packages through distro channels can be surprisingly  
difficult for new packages. :/


How neutron team can answer to this?
I think it is not specific to neutron subproject dashboard discussion.
Neutron stadium mode already has this problem.
Input from packaging side would be appreciated.


Distributions should work on fixing their processes. That’s what RDO  
project is going through right now (f.e. we got rid of Fedora package  
review process [that usually took too much time] as a prerequisite step for  
inclusion). But if you still feel issues with proposing a new package for  
RDO for neutron bits, please talk to me.


Ihar

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


Re: [openstack-dev] The command "neutron-db-manage" of 8.0.0~b1 fails

2016-01-04 Thread Ihar Hrachyshka

Martinx - ジェームズ  wrote:


Guys,

 I'm trying to experiment Mitaka on Ubuntu Xenial, which already have
beta version on its repositories, however, "neutron-db-manage" fails.

 Here is the output of it:

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

 Any clue?

 I'm using the Kilo instructions as a start point, of course, I'm
using new neutron.conf and new ml2_conf.ini as well.

Thanks in advance!
Thiago


I believe it was fixed in:  
https://review.openstack.org/#/c/253150/2/neutron/db/migration/alembic_migrations/versions/mitaka/contract/8a6d8bdae39_migrate_neutron_resources_table.py


Ihar

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


Re: [openstack-dev] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

2016-01-04 Thread Itxaka Serrano Garcia



Same issue on django_openstack_auth, kilo branch:

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


And same error too [0]:

2016-01-04 10:47:17.621 | Obtaining file:///opt/stack/new/keystone
2016-01-04 10:47:18.251 | Complete output from command python
setup.py egg_info:
2016-01-04 10:47:18.251 | ERROR:root:Error parsing
2016-01-04 10:47:18.251 | Traceback (most recent call last):
2016-01-04 10:47:18.251 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/core.py", line 109, in pbr
2016-01-04 10:47:18.251 | attrs = util.cfg_to_args(path)
2016-01-04 10:47:18.251 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/util.py", line 261, in
cfg_to_args
2016-01-04 10:47:18.251 | wrap_commands(kwargs)
2016-01-04 10:47:18.251 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/util.py", line 482, in
wrap_commands
2016-01-04 10:47:18.251 | for cmd, _ in dist.get_command_list():
2016-01-04 10:47:18.251 |   File
"/usr/local/lib/python2.7/dist-packages/setuptools/dist.py", line 446,
in get_command_list
2016-01-04 10:47:18.251 | cmdclass = ep.resolve()
2016-01-04 10:47:18.251 |   File
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
2386, in resolve
2016-01-04 10:47:18.251 | module = __import__(self.module_name,
fromlist=['__name__'], level=0)
2016-01-04 10:47:18.251 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/testr_command.py", line 47,
in 
2016-01-04 10:47:18.251 | from testrepository import commands
2016-01-04 10:47:18.251 | ImportError: No module named testrepository
2016-01-04 10:47:18.251 | error in setup command: Error parsing
/opt/stack/new/keystone/setup.cfg: ImportError: No module named
testrepository




[0]
http://logs.openstack.org/78/262778/2/check/gate-tempest-dsvm-neutron-src-django_openstack_auth/01220e8/logs/devstacklog.txt.gz


On 01/04/2016 09:13 AM, Matthias Runge wrote:

Hello,

did we had a recent change in stable tests for Kilo?

Horizon tests for kilo are now failing due to a missing dependency to
testrepository. Horizon never used testrepository (until recently,
where I added testr support, but only in mitaka branch).

As a test, I added a test dependency for kilo branch, but that fails
somewhere else due to missing testrepository:

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

The error is in [1] somewhere at the bottom:

É5-12-30 09:53:27.883 | Obtaining file:///opt/stack/new/keystone
2015-12-30 09:53:28.504 | Complete output from command python
setup.py egg_info:
2015-12-30 09:53:28.504 | ERROR:root:Error parsing
2015-12-30 09:53:28.504 | Traceback (most recent call last):
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/core.py", line 109, in pbr
2015-12-30 09:53:28.504 | attrs = util.cfg_to_args(path)
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/util.py", line 261, in
cfg_to_args
2015-12-30 09:53:28.504 | wrap_commands(kwargs)
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/util.py", line 482, in
wrap_commands
2015-12-30 09:53:28.504 | for cmd, _ in dist.get_command_list():
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/setuptools/dist.py", line 446,
in get_command_list
2015-12-30 09:53:28.504 | cmdclass = ep.resolve()
2015-12-30 09:53:28.505 |   File
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
2386, in resolve
2015-12-30 09:53:28.505 | module = __import__(self.module_name,
fromlist=['__name__'], level=0)
2015-12-30 09:53:28.505 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/testr_command.py", line 47,
in 
2015-12-30 09:53:28.505 | from testrepository import commands
2015-12-30 09:53:28.505 | ImportError: No module named
testrepository
2015-12-30 09:53:28.505 | error in setup command: Error parsing
/opt/stack/new/keystone/setup.cfg: ImportError: No module named
testrepository

Any suggestions here?

[1]
http://logs.openstack.org/96/262296/2/check/gate-tempest-dsvm-full/e47e5c6/logs/devstacklog.txt.gz





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


Re: [openstack-dev] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

2016-01-04 Thread Ihar Hrachyshka

Matthias Runge  wrote:


Hello,

did we had a recent change in stable tests for Kilo?

Horizon tests for kilo are now failing due to a missing dependency to
testrepository. Horizon never used testrepository (until recently,
where I added testr support, but only in mitaka branch).

As a test, I added a test dependency for kilo branch, but that fails
somewhere else due to missing testrepository:

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

The error is in [1] somewhere at the bottom:

É5-12-30 09:53:27.883 | Obtaining file:///opt/stack/new/keystone
2015-12-30 09:53:28.504 | Complete output from command python
setup.py egg_info:
2015-12-30 09:53:28.504 | ERROR:root:Error parsing
2015-12-30 09:53:28.504 | Traceback (most recent call last):
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/core.py", line 109, in pbr
2015-12-30 09:53:28.504 | attrs = util.cfg_to_args(path)
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/util.py", line 261, in
cfg_to_args
2015-12-30 09:53:28.504 | wrap_commands(kwargs)
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/util.py", line 482, in
wrap_commands
2015-12-30 09:53:28.504 | for cmd, _ in dist.get_command_list():
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/setuptools/dist.py", line 446,
in get_command_list
2015-12-30 09:53:28.504 | cmdclass = ep.resolve()
2015-12-30 09:53:28.505 |   File
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
2386, in resolve
2015-12-30 09:53:28.505 | module = __import__(self.module_name,
fromlist=['__name__'], level=0)
2015-12-30 09:53:28.505 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/testr_command.py", line 47,
in 
2015-12-30 09:53:28.505 | from testrepository import commands
2015-12-30 09:53:28.505 | ImportError: No module named
testrepository
2015-12-30 09:53:28.505 | error in setup command: Error parsing
/opt/stack/new/keystone/setup.cfg: ImportError: No module named
testrepository

Any suggestions here?


Seems like pbr importing testrepository, hence the dependency belongs to  
pbr, not horizon (and as a runtime dependency, not just test only).


But note that since pbr 1.1.0, they no longer depend on the package and  
fail gracefully:


https://github.com/openstack-dev/pbr/commit/946cf80b750f3735a5d3b0c2173f4eaa7fad4a81

So the proper way would be indeed to make your package to install testr for  
tests. Not sure why it worked before, but I would bet that some other  
components installed it for you (devstack? devstack-gate? job definition?  
some other component previously installed before keystone? Not that it’s  
too important.)


Ihar

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


Re: [openstack-dev] [puppet] adding puppet-rally to OpenStack

2016-01-04 Thread Emilien Macchi


On 12/31/2015 06:43 PM, Andy Botting wrote:
> Hi Emilien,
> 
> 
> I looked again at your module and I see two options:
> 
> * import your module in OpenStack and make it compliant (your module
> does not have tests, readme, and some pieces are missing), and cleanup a
> lot of things
> 
> 
> Just want to confirm you're looking at this new repo:
> https://github.com/andybotting/puppet-rally

Unfortunately, this is not the repository we were discussing in this
thread and I was not aware you would create a new one.

In the meantime, I created https://review.openstack.org/262970 which is
a bootstrap ready for basic structure.
What I suggest is to land it and then you can import your bits (init.pp
mainly) in openstack module.

Does it work for you?

> It was created following the guides you mentioned earlier, and does
> include tests, readme, etc
> 
> cheers,
> Andy

-- 
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] [heat][telemetry] gate-ceilometer-dsvm-integration broken

2016-01-04 Thread Steven Hardy
On Mon, Dec 28, 2015 at 01:52:45PM +0100, Julien Danjou wrote:
> On Mon, Dec 28 2015, Rabi Mishra wrote:
> 
> > Yes, this has started happening after keystone/trusts config changes by the
> > devstack patch you mentioned. I've no idea how this can be fixed. As Steve
> > Hardy is away, either someone with keystone knowledge should fix this or we
> > merge the devstack patch revert[3] that I tested few days ago.
> 
> Why don't you just revert the devstack change?
> 
> This is way saner than disabling the test! Steve will be able to rework
> his initial change when he come back.

Firstly, I'm very sorry for the breakage here, and I agree that in general
a quick-revert is the best policy when something like this happens.

I'm a little unclear how this occurred tho, since I had a clear CI run on
this patch:

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

Which had a Depends-On to the devstack change, anyone know why that didn't
fail with the CeilometerAlarmTest.test_alarm before the devstack change
merged?

Regardless, we've got several fixes now which can be considered:

1. Rabi's devstack revert:

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

2. Fix the actual issue in heat:

https://review.openstack.org/#/q/topic:bug/1529058

Given that the review latency on Devstack is quite high, it seems possible
we'll land (2) before (1) lands, but if not then I'll re-propose it and
hopefully figure out where I went wrong with Depends-On to confirm all is
fixed before it lands.

Also, there's this fix:

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

I've not yet confirmed if this also fixes the issue referencing the default
domain which broke the alarm tests.

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] [heat][telemetry] gate-ceilometer-dsvm-integration broken

2016-01-04 Thread Rabi Mishra
> 
> Hi,
> 
> >> Which had a Depends-On to the devstack change, anyone know why that
> >> didn't
> >> fail with the CeilometerAlarmTest.test_alarm before the devstack
> >> change
> >> merged?
> > 
> > It seems the test was skipped[1], as it was disabled for another
> > bug[2].
> > 
> > [1]
> > http://logs.openstack.org/15/256315/2/check/gate-heat-dsvm-functional-orig-mysql/bffccd5/console.html.gz#_2015-12-14_23_33_13_394
> > [2] https://bugs.launchpad.net/heat/+bug/1523337
> 
> This is unrelated, this is an old issue, this bug have already been
> fixed in Aodh[1], and Heat have re-enabled the ceilometer tests [2] just
> after the fix was merged.

Sure, the issues are unrelated. However, the patch with ceilometer test 
re-enabled landed on 16th Dec[1] and CI run for Steve's patch with 'Depends-On' 
was on 15th Dec[2], while the test was still disabled:)

Hope this clarifies why we missed the regression.

[1] https://review.openstack.org/#/c/254081/
[2] https://review.openstack.org/#/c/256315/
 
> I think we just forget to set the status of #1523337 (heat side) when
> [2] was merged. (I have just set it)
> 
> [1] https://review.openstack.org/#/c/254078/
> [2]
> http://git.openstack.org/cgit/openstack/heat/commit/?id=53e16655ab899f56bd0fd5d4997bb27a76be53df
> 

__
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] Nova API sub-team meeting

2016-01-04 Thread Alex Xu
Hi,

Welcome back everyone and happy new year! We have
weekly Nova API meeting this week. The meeting is being held Tuesday
UTC1200.

The proposed agenda and meeting details are here:

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

Please feel free to add items to the agenda.

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


Re: [openstack-dev] [all] IRC meetings warning: two "odd" weeks coming up

2016-01-04 Thread Thierry Carrez

Thierry Carrez wrote:

Bi-weekly meetings are going to be affected by the new year, as two odd
ISO week numbers are following each other.

Week 52: Dec 21 - Jan 27
Week 53: Dec 28 - Jan 3
Week 1:  Jan 4 - Jan 10

https://en.wikipedia.org/wiki/ISO_week_date

That means on the week of Jan 4th we'll hold "biweekly-odd" meetings,
and not "biweekly-even" meetings.

Unfortunately, to add to the confusion, the subtlety of two odd weeks
following each other is lost to yaml2ical: it just generates an iCal
that puts biweekly meetings every two weeks starting from the generation
date. This bug will cause the generated iCal to be off (showing
biweekly-odd meetings on that week) until it's regenerated on week 1.


The ICS on eavesdrop.openstack.org was just regenerated, so meetings for 
this week should now appear correctly.


Cheers and happy new year !

--
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] [kolla] Adding Ubuntu Liberty to Kolla-Mitaka

2016-01-04 Thread Thomas Goirand
On 01/03/2016 10:45 PM, Sam Yaple wrote:
> That said if you have a link to the project-config patch I will be more than
> happy to review it and follow it.

My point being: I don't even know where to start. I need someone to help
me start it, and then, I can fix/enhance/improve it.

And yes, I did try, and read the docs. Any pointers would be helpful.

Cheers,

Thomas Goirand (zigo)


__
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] [heat][telemetry] gate-ceilometer-dsvm-integration broken

2016-01-04 Thread Julien Danjou
On Mon, Jan 04 2016, Steven Hardy wrote:

Hi,

> Firstly, I'm very sorry for the breakage here, and I agree that in general
> a quick-revert is the best policy when something like this happens.

No problem Steven, shit happens.

It'd be even better if Heat'd move to a devstack plugin to limit this
kind of high level latency. Just by curiosity, is there a plan for that?

> I'm a little unclear how this occurred tho, since I had a clear CI run on
> this patch:
>
> https://review.openstack.org/#/c/256315/

I think the dsvm tests are not the same that we run on telemetry side:
we run it with the Gnocchi backend, whereas you're likely using the
(old) Ceilometer backend. And that's the Gnocchi backend that has been
broken by the original devstack change from what I saw.

Maybe Heat should also run this job, WDYT?

> Given that the review latency on Devstack is quite high, it seems possible
> we'll land (2) before (1) lands, but if not then I'll re-propose it and
> hopefully figure out where I went wrong with Depends-On to confirm all is
> fixed before it lands.

Yeah, whatever fixes the issue I'm ok with. :-) If you can fix Heat
faster, that'd be even cooler.

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


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


Re: [openstack-dev] [heat][telemetry] gate-ceilometer-dsvm-integration broken

2016-01-04 Thread Steven Hardy
On Mon, Jan 04, 2016 at 11:31:40AM +0100, Julien Danjou wrote:
> On Mon, Jan 04 2016, Steven Hardy wrote:
> 
> Hi,
> 
> > Firstly, I'm very sorry for the breakage here, and I agree that in general
> > a quick-revert is the best policy when something like this happens.
> 
> No problem Steven, shit happens.
> 
> It'd be even better if Heat'd move to a devstack plugin to limit this
> kind of high level latency. Just by curiosity, is there a plan for that?

Yes, it was discussed in a recent Heat meeting, and IIRC pas-ha was going
to work on it, I agree it's a good idea and should enable more responsive
updates/fixes to our devstack config.

> > I'm a little unclear how this occurred tho, since I had a clear CI run on
> > this patch:
> >
> > https://review.openstack.org/#/c/256315/
> 
> I think the dsvm tests are not the same that we run on telemetry side:
> we run it with the Gnocchi backend, whereas you're likely using the
> (old) Ceilometer backend. And that's the Gnocchi backend that has been
> broken by the original devstack change from what I saw.
> 
> Maybe Heat should also run this job, WDYT?

We'll have to look into that - I was assuming all our jobs should move to
using Gnocchi by default now?

Rabi has acutally pointed out that we'd already skipped the heat alarm test
due to a previous issue (doh!) which is probably why my Depends-On didn't
catch this regression, so at least that is now understood :)

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] [heat][telemetry] gate-ceilometer-dsvm-integration broken

2016-01-04 Thread Mehdi Abaakouk


Hi,

Which had a Depends-On to the devstack change, anyone know why that 
didn't
fail with the CeilometerAlarmTest.test_alarm before the devstack 
change

merged?


It seems the test was skipped[1], as it was disabled for another 
bug[2].


[1]
http://logs.openstack.org/15/256315/2/check/gate-heat-dsvm-functional-orig-mysql/bffccd5/console.html.gz#_2015-12-14_23_33_13_394
[2] https://bugs.launchpad.net/heat/+bug/1523337


This is unrelated, this is an old issue, this bug have already been 
fixed in Aodh[1], and Heat have re-enabled the ceilometer tests [2] just 
after the fix was merged.


I think we just forget to set the status of #1523337 (heat side) when 
[2] was merged. (I have just set it)


[1] https://review.openstack.org/#/c/254078/
[2] 
http://git.openstack.org/cgit/openstack/heat/commit/?id=53e16655ab899f56bd0fd5d4997bb27a76be53df


__
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] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

2016-01-04 Thread Matthias Runge
Hello,

did we had a recent change in stable tests for Kilo?

Horizon tests for kilo are now failing due to a missing dependency to
testrepository. Horizon never used testrepository (until recently,
where I added testr support, but only in mitaka branch).

As a test, I added a test dependency for kilo branch, but that fails
somewhere else due to missing testrepository:

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

The error is in [1] somewhere at the bottom:

É5-12-30 09:53:27.883 | Obtaining file:///opt/stack/new/keystone
2015-12-30 09:53:28.504 | Complete output from command python
setup.py egg_info:
2015-12-30 09:53:28.504 | ERROR:root:Error parsing
2015-12-30 09:53:28.504 | Traceback (most recent call last):
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/core.py", line 109, in pbr
2015-12-30 09:53:28.504 | attrs = util.cfg_to_args(path)
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/util.py", line 261, in
cfg_to_args
2015-12-30 09:53:28.504 | wrap_commands(kwargs)
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/util.py", line 482, in
wrap_commands
2015-12-30 09:53:28.504 | for cmd, _ in dist.get_command_list():
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/setuptools/dist.py", line 446,
in get_command_list
2015-12-30 09:53:28.504 | cmdclass = ep.resolve()
2015-12-30 09:53:28.505 |   File
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
2386, in resolve
2015-12-30 09:53:28.505 | module = __import__(self.module_name,
fromlist=['__name__'], level=0)
2015-12-30 09:53:28.505 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/testr_command.py", line 47,
in 
2015-12-30 09:53:28.505 | from testrepository import commands
2015-12-30 09:53:28.505 | ImportError: No module named
testrepository
2015-12-30 09:53:28.505 | error in setup command: Error parsing
/opt/stack/new/keystone/setup.cfg: ImportError: No module named
testrepository

Any suggestions here?

[1]
http://logs.openstack.org/96/262296/2/check/gate-tempest-dsvm-full/e47e5c6/logs/devstacklog.txt.gz
-- 
Matthias Runge 

__
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] [senlin] Midcycle meetup (2016-01-11/12)

2016-01-04 Thread Ethan Lynn
Finally I get a chance to see you all!

Best Regards,
Ethan Lynn



> On Dec 28, 2015, at 17:54, Yanyan Hu  wrote:
> 
> Great! Can't wait to see you guys :) 
> 
> 2015-12-28 10:03 GMT+08:00 Qiming Teng  >:
> Dear all,
> 
> Wish you all a merry christmas and a happy new year.
> 
> Senlin team is planning a mid-cycle meetup next month in Beijing. Well,
> it goes beyond just a meetup between developers. We are inviting some
> users to share their real-life use cases and requirements.
> 
> IBM Research China Lab will host the event. Please find the schedule
> etherpad here: https://etherpad.openstack.org/p/senlin-mitaka-midcycle 
> 
> 
> Any comments/suggestions are welcomed. We are looking forward to see you
> guys.
> 
> Regards,
>   Qiming
> 
> 
> __
> 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,
> 
> Yanyan
> __
> 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] [devstack][heat][telemetry] gate-ceilometer-dsvm-integration broken

2016-01-04 Thread Julien Danjou
On Mon, Dec 28 2015, Julien Danjou wrote:

> On Mon, Dec 28 2015, Rabi Mishra wrote:
>
>> Yes, this has started happening after keystone/trusts config changes by the
>> devstack patch you mentioned. I've no idea how this can be fixed. As Steve
>> Hardy is away, either someone with keystone knowledge should fix this or we
>> merge the devstack patch revert[3] that I tested few days ago.
>
> Why don't you just revert the devstack change?
>
> This is way saner than disabling the test! Steve will be able to rework
> his initial change when he come back.
>
> I've commented on the patches with that.

So can we have https://review.openstack.org/#/c/261308/ merged today,
please devstack team? The gate for Gnocchi, Aodh and Ceilometer has now
been broken for 10 days. I think it's long enough.

Thanks!

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


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


[openstack-dev] [cinder] Object backporting and the associated service

2016-01-04 Thread Ryan Rossiter
Hey everybody, your favorite versioned objects guy is back!

So as I’m helping out more and more with the objects stuff around Cinder, I’m 
starting to notice something that may be a problem with rolling upgrades/object 
backporting. Feel free to say “you’re wrong” at any point during this email, I 
very well may have missed something.

My first question is: what will be handling the object backports that the 
different cinder services need? In Nova, we have the conductor service, which 
handles all of the messy RPC and DB work. When anyone needs something 
backported, they ask conductor, and it handles everything. That also gives us a 
starting point for the rolling upgrades: start with conductor, and now he has 
the new master list of objects, and can handle the backporting of objects when 
giving them to the older services. From what I see, the main services in cinder 
are API, scheduler, and volume. Does there need to be another service added to 
handle RPC stuff?

The next question is: are there plans to do manifest backports? That is a very 
o.vo-jargoned question, but basically from what I can see, Cinder’s 
obj_to_primitive() calls do not use o.vo’s newer method of backporting, which 
uses a big dictionary of known versions (a manifest) to do one big backport 
instead of clogging up RPC with multiple backport requests every time a 
subobject needs to be backported after a parent has been backported (see [1] if 
you’re interested). I think this is a pretty simple change that I can help out 
with if need be (/me knocks on wood).

I don’t mean to pile more work onto this, I understand that this is a big task 
to take on, and so far, it’s progressing very well. Michal’s been really 
helpful as a liaison so far, he’s been a lot of help :).

[1] 
https://github.com/openstack/oslo.versionedobjects/blob/master/oslo_versionedobjects/base.py#L522

-
Thanks,

Ryan Rossiter (rlrossit)


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


Re: [openstack-dev] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

2016-01-04 Thread Robert Collins
On 5 January 2016 at 11:59, Robert Collins  wrote:
> This is odd indeed. pbr is not meant to have a dep on testrepository,
> and you can see in
> https://git.openstack.org/cgit/openstack-dev/pbr/tree/pbr/testr_command.py#n150
> that we only access it if it is installed and we use latest pbr
> everywhere because otherwise we can't deal with ecosystem changes to
> e.g. setuptools or pip.
>
> http://logs.openstack.org/96/262296/2/check/gate-tempest-dsvm-full/e47e5c6/logs/devstacklog.txt.gz#_2015-12-30_09_53_14_200
> shows that the latest pbr (1.8.1 which would work) is being
> downgraded. Thats when the problem is introduced. However, kilo has
> that special thing where pbr is capped because a lot of dependencies
> error due to version disagreements (not API breaks - pbr is
> compatible!), so this is expected :(.
>
> I'm not sure what has caused testrepository to not be installed in
> this scenario, but thats what I'd be looking at.
>

Further to that, I suspect setuptools may have changed -
https://pypi.python.org/pypi/setuptools - 19.2 was released
suspiciously close to the point errors were reported (25th dec).

Looking now..

-Rob


-- 
Robert Collins 
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] [Horizon] Mid-cycle Sprint

2016-01-04 Thread Thai Q Tran
FYI, Cindy and I will put in a request for travel approval. Also, I have spoken to Mariam and would be willing to mentor David.
 
- Original message -From: David Lyle To: OpenStack Development Mailing List Cc:Subject: [openstack-dev] [Horizon] Mid-cycle SprintDate: Mon, Dec 28, 2015 11:22 AM 
The Horizon mid-cycle sprint is in Hillsboro, Oregon Feb 23-25 andhosted at the Intel site in Hillsboro just west of Portland.The wiki for the mid-cycle sprint ishttps://wiki.openstack.org/wiki/Sprints/HorizonMitakaSprintPlease note your intention to attend on the wiki page.Thanks,David__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 
 


__
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] Versioning of the fwaas API

2016-01-04 Thread Eichberger, German
In LBaaS with going with two distinct endpoints we were sort of skirting the 
backwards compatibility problem, e.g. People need to go full V2 with their 
infrastructure or stay at V1. This was informed by our understanding that 
nobody in his right mind would run V1… but believe me people are crazy :-)

IN LBaaS we also didn’t allow to run V1 and V2 side-by-side aka you had to 
choose only one for your installation. I think we could technically achieve 
that (especially if we have a new DB for V2) but I am not sure if it’s worth 
the hassle...

For LBaaS doing the hard break had side effects: Despite the API being around 
for two cycles we still don’t have Horizon support in LBaaS V2 (which is 
changing) - so if we can avoid the hard break in FWaaS and invest in some API 
compatibility layer all those things like Horizon, Heat, etc. can update at 
their leisure while still working with V2. That is the first thing which needs 
to be decided.

Secondly, if we decide that we allow the use of both versions side-by-side that 
will ask for a different design than if we would just do a hard breaK. So let’s 
assume we have an API compatibility layer than I would think the [3] would work 
with the new stuff using the custom header and the old stuff would not. 

German



On 1/2/16, 4:03 PM, "Brandon Logan"  wrote:

>On Sat, 2016-01-02 at 22:23 +, Sean M. Collins wrote:
>> I was on Twitter and got linked to this blog post[1], and then got
>> linked over to Terraform's docs, and of course I went and checked out
>> its support for OpenStack.
>> 
>> Well, what do you know? It has support for Firewall[2]! Yay!
>> 
>> Based on the fact that we have a spec for a v2 API - the question
>> becomes - how do we not break all this?
>> 
>> I see that LBaaS went the route of
>> 
>> v1 api = "/lb"
>> v2 api = "/lbaas"
>> 
>> https://github.com/openstack/neutron-lbaas/blob/master/neutron_lbaas/extensions/loadbalancer.py#L32
>> 
>> https://github.com/openstack/neutron-lbaas/blob/master/neutron_lbaas/extensions/loadbalancerv2.py#L34
>> 
>
>Yeah, this was kind of a best bad option at the time.
>
>> So - I guess we take the same route with FwaaS - maybe have the endpoint
>> at "/fwaas" and then hopefully we can implement microversioning[3]? That
>> way, we never have to make another endpoint like "/firewall" if we come up 
>> with a v3 API in the 2020s.
>
>I hope too that microversioning will fix this as well, but I'm not so
>sure it will as it is proposed.  I might be overlooking something but I
>can't seem how a neutron microversion can handle both neutron's api and
>a fwaas/lbaas/vpnaas api that may or may not be enabled.
>
>Definitely needs more discussion though, because it would be nice if it
>does solve this problem.
>
>> 
>> [1]: http://tech.paulcz.net/2016/01/openstacks-and-ecosystems/
>> 
>> [2]: https://terraform.io/docs/providers/openstack/r/fw_firewall_v1.html
>> 
>> [3]: 
>> http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html
>> 
>
>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 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] Austin Summit Panel on Generation of Sample Configuration Option Files

2016-01-04 Thread Ben Nemec
On 01/04/2016 03:50 PM, Kendall J Nelson wrote:
> Hello,
> 
> 
> In brainstorming ideas for talks at the upcoming summit, I thought about
> some of the things I had worked on for Cinder and what could still be
> improved. One of the things I have been looking into is the generation
> of sample configuration option files. Upon initial research it looks
> like none of the main projects are doing it the same way. 

I'm not sure what you mean.  Nova, Neutron, Keystone, Glance, and Heat
(at least) are all using the oslo-config-generator tool for this.  There
might be some slight variation in how they call it, but they are using it.

I only vaguely recall having discussions about this with Cinder, so I'd
be interested in a refresher around why Cinder didn't want to do it the
same way.  I kind of considered it a solved problem.

For reference:
Nova: https://github.com/openstack/nova/blob/master/tox.ini#L90
Neutron: https://github.com/openstack/neutron/blob/master/tox.ini#L198
which calls
https://github.com/openstack/neutron/blob/master/tools/generate_config_file_samples.sh#L17
Keystone: https://github.com/openstack/keystone/blob/master/tox.ini#L148
Etc...

> I thought it
> might be interesting to get a panel together to talk about how it is
> done for each project, why it is done that way for each project, and
> maybe discuss a more universal approach that could be implemented in
> oslo and used by all the projects. Please let me know if you have
> knowledge on your project’s method and are interested in being part of a
> panel.
> 
> 
> If you are interested in looking at Cinder’s approach, here is the patch
> I implemented to make the generation of the sample config file dynamic:
> https://review.openstack.org/#/c/219700/
> 
> 
> All the Best,
> 
> *Kendall J. Nelson*
> Software Engineer &
> 
> Openstack Cinder Contributor
> 
> *E-mail:*_kjnel...@us.ibm.com_ 
> *Cell Phone:*(952) 215- 4025*
> IRC Nickname:*diablo_rojo 
> IBM
> 
> 3605 Hwy 52 N
> Rochester, MN 55901-1407
> United States
> 
> 
> 
> 
> 
> __
> 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] [all] Austin Summit Panel on Generation of Sample Configuration Option Files

2016-01-04 Thread Kendall J Nelson


Hello,



  In brainstorming ideas for talks at the upcoming summit, I thought
about some of the things I had worked on for Cinder and what could still be
improved. One of the things I have been looking into is the generation of
sample configuration option files. Upon initial research it looks like none
of the main projects are doing it the same way. I thought it might be
interesting to get a panel together to talk about how it is done for each
project, why it is done that way for each project, and maybe discuss a more
universal approach that could be implemented in oslo and used by all the
projects. Please let me know if you have knowledge on your project’s method
and are interested in being part of a panel.



If you are interested in looking at Cinder’s approach, here is the patch I
implemented to make the generation of the sample config file dynamic:
https://review.openstack.org/#/c/219700/


All the Best,
  
   Kendall J. Nelson  
   Software Engineer &
  


Openstack Cinder Contributor
   
   
   
   E-mail: kjnel...@us.ibm.com IBM 
   Cell Phone: (952) 215- 4025 
   IRC Nickname: diablo_rojo 3605 Hwy 52 N 
 Rochester, MN 
55901-1407 
 United States 
   

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


Re: [openstack-dev] [TripleO] Is Swift a good choice of database for the TripleO API?

2016-01-04 Thread Zane Bitter

On 22/12/15 11:56, Clint Byrum wrote:

Excerpts from Dougal Matthews's message of 2015-12-22 07:36:02 -0800:

Hi all,

This topic came up in the 2015-12-15 meeting[1], and again briefly today.
After working with the code that came out of the deployment library spec[2]
I
had some concerns with how we are storing the templates.

Simply put, when we are dealing with 100+ files from tripleo-heat-templates
how can we ensure consistency in Swift without any atomicity or
transactions.
I think this is best explained with a couple of examples.

  - When we create a new deployment plan (upload all the templates to swift)
how do we handle the case where there is an error? For example, if we are
uploading 10 files - what do we do if the 5th one fails for some reason?
There is a patch to do a manual rollback[3], but I have concerns about
doing this in Python. If Swift is completely inaccessible for a short
period the rollback wont work either.



You could create a unique swift container, upload things to that, and
then update a pointer in a well-known location to point at that container
for the new plan only after you've verified it is available. This is a
primitive form of Read-copy-update.


+1, I think immutable files (actually, whole containers) is the correct 
way to use Swift if we're going to use it (which, for the record, I 
think we should). This is how Glance stores disk images, and also how 
the 
Glance-artifact-store-that-is-now-a-separate-metadata-service-with-a-different-name 
(help me out here) worked/works. Ideally we'd use that to store any 
metadata, but a (mutable) pointer in Swift to the latest is probably 
sufficient for this use case.



  - When deploying to Heat, we need to download all the YAML files from
Swift.
This can take a couple of seconds. What happens if somebody starts to
upload a new version of the plan in the middle? We could end up trying to
deploy half old and half new files. We wouldn't have a consistent view of
the database.



Perhaps you should land a change in Heat to allow templates to be directly
downloaded by the engine from swift without needing to be uploaded.


Yes, we should definitely add this in Heat.


In
the past allowing URLs to be downloaded unfettered was disabled because
we don't want Heat to be a DoS engine, but swift would be in-cloud and
could be restricted to the stack owner.


Actually, it's still allowed (but not used by python-heatclient) to 
preserve backward compatibility, and likely won't be removed until a v2 
API spin :/



We had a few suggestions in the meeting:

  - Add a locking mechanism. I would be concerned about deadlocks or having
to
lock for the full duration of a deploy.


Deadlocks only happen when competing interests lock _two_ things in
different order. Have one thing to lock, and you don't have to worry
about this.


  - Store the files in a tarball (so we only deal with one file). I think we
could still hit issues with multiple operations unless we guarantee that
only one instance of the API is ever running.


I think immutable data is a better solution; you can't pass a tarball to 
Heat.



I think these could potentially be made to work, but at this point are we
using the best tool for the job?

For alternatives, I see a can think of a couple of options:

- Use a database, like we did for Tuskar and most OpenStack API's do.


This makes me deeply uneasy; I think one of the lessons of Tuskar is 
that putting the templates in a database accessible only from the API 
dramatically reduces our flexibility while not buying us anything in 
particular.


cheers,
Zane.



It's worth noting that many OpenStack API's/daemons are using the
database + MQ to provide consistency in a distributed fashion, and many
have identified that this doesn't scale particularly well, and looking
at tooz to help bring in DLM's. In fact, a spec recently landed around
this:

http://specs.openstack.org/openstack/openstack-specs/specs/chronicles-of-a-dlm.html

So if you are only using the DB for consistency, you might want to just
use tooz+swift.


- Invest time in building something on Swift.
- Glance was transitioning to be a Artifact store. I don't know the status
of
   this or if it would meet out needs.


I'd say the artifact store is more about exposing options to users, and
less about providing primitives for an API.

__
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] [glance] Seeking FFE for "Support single disk image OVA/OVF package upload"

2016-01-04 Thread Bhandaru, Malini K
Hello Glance Team!
Hope you had a wonderful vacation and wishing you health and 
happiness for 2016.

Would very much appreciate your considering https://review.openstack.org/194868 
for a feature freeze exception.

I believe the spec is pretty solid, and we can deliver on the implementation by 
M-2. But were unable to get enough core

Votes during the holiday season.

Regards

Malini


__
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] [devstack] [neutron] Procedure for back-porting a bug fix to stable/liberty branch of a Neutron script in DevStack?

2016-01-04 Thread Mike Spreitzer
> From: Kyle Mestery 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 01/03/2016 02:15 PM
> Subject: Re: [openstack-dev] [devstack] [neutron] Procedure for 
> back-porting a bug fix to stable/liberty branch of a Neutron script 
> in DevStack?
> 
> On Sun, Jan 3, 2016 at 4:01 PM, Mike Spreitzer  
wrote:
> I would like to back-port https://review.openstack.org/#/c/242721/
> --- which fixed https://bugs.launchpad.net/devstack/+bug/1469596--- 
> to stable/liberty.  I have contributed to main line development 
> before, but not stable branches.  I see that http://
> docs.openstack.org/infra/manual/developers.htmldoes not specifically
> address this case.  What is the procedure to follow?

> The best place to look is in the project team guide [1], 
> specifically the section on proposing fixes.
> 
> [1] http://docs.openstack.org/project-team-guide/stable-branches.html
> [2] 
http://docs.openstack.org/project-team-guide/stable-branches.html#proposing-fixes


Reference [2] says I should

$ git checkout stable/tango

but that doesn't work.  Here is a typescript of how it goes wrong:

mjs10:devstack mspreitz$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

mjs10:devstack mspreitz$ git pull
Already up-to-date.

mjs10:devstack mspreitz$ git remote -v
gerrit 
ssh://mspre...@review.openstack.org:29418/openstack-dev/devstack.git 
(fetch)
gerrit 
ssh://mspre...@review.openstack.org:29418/openstack-dev/devstack.git 
(push)
origin  https://github.com/openstack-dev/devstack.git (fetch)
origin  https://github.com/openstack-dev/devstack.git (push)

mjs10:devstack mspreitz$ git checkout stable/liberty
error: pathspec 'stable/liberty' did not match any file(s) known to git.



__
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] Austin Summit Panel on Generation of Sample Configuration Option Files

2016-01-04 Thread Joshua Harlow

So just out of curiosity:

https://review.openstack.org/#/c/219700/14/cinder/config/generate_cinder_opts.py

Why does this not use 
https://github.com/openstack/cinder/blob/master/setup.cfg#L44 to find 
the exposed cinder configuration options (and drivers that cinder 
has/provides should expose a similar entrypoint and so-on)?


Also just brainstorming, but said 'generate_cinder_opts.py' should 
likely also have the output of `pip freeze` (sorted and canonicalized 
would be best to) because the generated opts that are found in other 
libraries (those libraries should/typically expose an entrypoint to list 
there own opts) depend on *exactly* what version of the package(s) is 
installed (yes I know this makes the application <-> library API for 
those libraries extremely weak/non-existent but this is how things have 
gone).


-Josh

Kendall J Nelson wrote:

Hello,


In brainstorming ideas for talks at the upcoming summit, I thought about
some of the things I had worked on for Cinder and what could still be
improved. One of the things I have been looking into is the generation
of sample configuration option files. Upon initial research it looks
like none of the main projects are doing it the same way. I thought it
might be interesting to get a panel together to talk about how it is
done for each project, why it is done that way for each project, and
maybe discuss a more universal approach that could be implemented in
oslo and used by all the projects. Please let me know if you have
knowledge on your project’s method and are interested in being part of a
panel.


If you are interested in looking at Cinder’s approach, here is the patch
I implemented to make the generation of the sample config file dynamic:
https://review.openstack.org/#/c/219700/


All the Best,

*Kendall J. Nelson*
Software Engineer &

Openstack Cinder Contributor

*E-mail:*_kjnel...@us.ibm.com_ 
*Cell Phone:*(952) 215- 4025*
IRC Nickname:*diablo_rojo   
IBM

3605 Hwy 52 N
Rochester, MN 55901-1407
United States



__
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] [devstack] [neutron] Procedure for back-porting a bug fix to stable/liberty branch of a Neutron script in DevStack?

2016-01-04 Thread Sean Dague
On 01/04/2016 04:34 PM, Mike Spreitzer wrote:
>> From: Kyle Mestery 
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: 01/03/2016 02:15 PM
>> Subject: Re: [openstack-dev] [devstack] [neutron] Procedure for
>> back-porting a bug fix to stable/liberty branch of a Neutron script
>> in DevStack?
>>
>> On Sun, Jan 3, 2016 at 4:01 PM, Mike Spreitzer 
> wrote:
>> I would like to back-port https://review.openstack.org/#/c/242721/
>> --- which fixed https://bugs.launchpad.net/devstack/+bug/1469596---
>> to stable/liberty.  I have contributed to main line development
>> before, but not stable branches.  I see that http://
>> docs.openstack.org/infra/manual/developers.htmldoes not specifically
>> address this case.  What is the procedure to follow?
> 
>> The best place to look is in the project team guide [1],
>> specifically the section on proposing fixes.
>>
>> [1] http://docs.openstack.org/project-team-guide/stable-branches.html
>> [2]
> http://docs.openstack.org/project-team-guide/stable-branches.html#proposing-fixes
> 
> Reference [2] says I should
> 
> $ git checkout stable/tango
> 
> but that doesn't work.  Here is a typescript of how it goes wrong:
> 
> mjs10:devstack mspreitz$ git status
> On branch master
> Your branch is up-to-date with 'origin/master'.
> nothing to commit, working directory clean
> 
> mjs10:devstack mspreitz$ git pull
> Already up-to-date.
> 
> mjs10:devstack mspreitz$ git remote -v
> gerrit  
>  ssh://mspre...@review.openstack.org:29418/openstack-dev/devstack.git
> (fetch)
> gerrit  
>  ssh://mspre...@review.openstack.org:29418/openstack-dev/devstack.git (push)
> originhttps://github.com/openstack-dev/devstack.git(fetch)
> originhttps://github.com/openstack-dev/devstack.git(push)
> 
> mjs10:devstack mspreitz$ git checkout stable/liberty
> error: pathspec 'stable/liberty' did not match any file(s) known to git.

The first time you do this you need to set up a tracking branch:

git checkout -t origin/stable/liberty

will get you one.

https://review.openstack.org/263456 is a proposed doc fix for this.

-Sean

-- 
Sean Dague
http://dague.net

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


Re: [openstack-dev] [TripleO] Is Swift a good choice of database for the TripleO API?

2016-01-04 Thread Fox, Kevin M
The glance artefact service is glare.

swift isn't atomic though. you can get inconsistent reads for a while between 
different files that can cause issues.

big +1 for making a glare artefact type for a set of heat templates. My heat 
templates are usually a collection of nested templates, and they often need to 
be the same version all together to work. doing that via http is kind of 
painful. Loading them in all at once and treating the result as a template set 
would be soo much better.

Thanks,
Kevin

From: Zane Bitter [zbit...@redhat.com]
Sent: Monday, January 04, 2016 2:55 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [TripleO] Is Swift a good choice of database for 
the TripleO API?

On 22/12/15 11:56, Clint Byrum wrote:
> Excerpts from Dougal Matthews's message of 2015-12-22 07:36:02 -0800:
>> Hi all,
>>
>> This topic came up in the 2015-12-15 meeting[1], and again briefly today.
>> After working with the code that came out of the deployment library spec[2]
>> I
>> had some concerns with how we are storing the templates.
>>
>> Simply put, when we are dealing with 100+ files from tripleo-heat-templates
>> how can we ensure consistency in Swift without any atomicity or
>> transactions.
>> I think this is best explained with a couple of examples.
>>
>>   - When we create a new deployment plan (upload all the templates to swift)
>> how do we handle the case where there is an error? For example, if we are
>> uploading 10 files - what do we do if the 5th one fails for some reason?
>> There is a patch to do a manual rollback[3], but I have concerns about
>> doing this in Python. If Swift is completely inaccessible for a short
>> period the rollback wont work either.
>>
>
> You could create a unique swift container, upload things to that, and
> then update a pointer in a well-known location to point at that container
> for the new plan only after you've verified it is available. This is a
> primitive form of Read-copy-update.

+1, I think immutable files (actually, whole containers) is the correct
way to use Swift if we're going to use it (which, for the record, I
think we should). This is how Glance stores disk images, and also how
the
Glance-artifact-store-that-is-now-a-separate-metadata-service-with-a-different-name
(help me out here) worked/works. Ideally we'd use that to store any
metadata, but a (mutable) pointer in Swift to the latest is probably
sufficient for this use case.

>>   - When deploying to Heat, we need to download all the YAML files from
>> Swift.
>> This can take a couple of seconds. What happens if somebody starts to
>> upload a new version of the plan in the middle? We could end up trying to
>> deploy half old and half new files. We wouldn't have a consistent view of
>> the database.
>>
>
> Perhaps you should land a change in Heat to allow templates to be directly
> downloaded by the engine from swift without needing to be uploaded.

Yes, we should definitely add this in Heat.

> In
> the past allowing URLs to be downloaded unfettered was disabled because
> we don't want Heat to be a DoS engine, but swift would be in-cloud and
> could be restricted to the stack owner.

Actually, it's still allowed (but not used by python-heatclient) to
preserve backward compatibility, and likely won't be removed until a v2
API spin :/

>> We had a few suggestions in the meeting:
>>
>>   - Add a locking mechanism. I would be concerned about deadlocks or having
>> to
>> lock for the full duration of a deploy.
>
> Deadlocks only happen when competing interests lock _two_ things in
> different order. Have one thing to lock, and you don't have to worry
> about this.
>
>>   - Store the files in a tarball (so we only deal with one file). I think we
>> could still hit issues with multiple operations unless we guarantee that
>> only one instance of the API is ever running.

I think immutable data is a better solution; you can't pass a tarball to
Heat.

>> I think these could potentially be made to work, but at this point are we
>> using the best tool for the job?
>>
>> For alternatives, I see a can think of a couple of options:
>>
>> - Use a database, like we did for Tuskar and most OpenStack API's do.

This makes me deeply uneasy; I think one of the lessons of Tuskar is
that putting the templates in a database accessible only from the API
dramatically reduces our flexibility while not buying us anything in
particular.

cheers,
Zane.

>
> It's worth noting that many OpenStack API's/daemons are using the
> database + MQ to provide consistency in a distributed fashion, and many
> have identified that this doesn't scale particularly well, and looking
> at tooz to help bring in DLM's. In fact, a spec recently landed around
> this:
>
> http://specs.openstack.org/openstack/openstack-specs/specs/chronicles-of-a-dlm.html
>
> So if you are only using the DB for consistency, you might want to just
> use 

Re: [openstack-dev] [Nova][Glance] Nova + Glance_v2 = Love

2016-01-04 Thread Zhenyu Zheng
Agreed with Sam, the point 6 is actually very important now for production
deployment, as volume-backed instance is very common. Maybe we should keep
it until we find a better solution.

On Tue, Dec 29, 2015 at 9:41 PM, Sam Matzek  wrote:

> On Thu, Dec 24, 2015 at 7:49 AM, Mikhail Fedosin 
> wrote:
> > Hello, it's another topic about glance v2 adoption in Nova, but it's
> > different from the others. I want to declare that there is a set of
> commits,
> > that make Nova version agnostic and allow to work with both glance apis.
> The
> > idea of the solution is to determine the current api version in the
> > beginning and make appropriate requests after.
> > (https://review.openstack.org/#/c/228578/,
> > https://review.openstack.org/#/c/238309/,
> > https://review.openstack.org/#/c/259097/)
> >
> > Indeed, it requires some additional (and painful) work, but now all
> tempest
> > tests pass in Jenkins.
> >
> > Note: this thread is not about xenplugin, there is another topic, called
> > 'Xenplugin + Glance_v2 = Hate'
> >
> > Here the main issues we faced and how we've solved them:
> >
> > 1. "changes-since" filter for image-list is not supported in v2 api.
> Steve
> > Lewis made a great job and implemented a set of filters with comparison
> > operators https://review.openstack.org/#/c/197388/. Filtering by
> > 'changes-since' is completely similar to 'gte:updated_at'.
> >
> > 2. Filtering by custom properties must have prefix 'property-'. In v2
> it's
> > not required.
> >
> > 3. V2 states that all custom properties must be image attributes, but
> Nova
> > assumes that they are included in 'properties' dictionary. It's fixed
> with
> > glanceclient's method 'is_base_property(prop_name)', that returns False
> in
> > case of custom property.
> >
> > 4. is_public=True/False is visibility="public"/"private" respectively.
> >
> > 5. Deleting custom image properties in Nova is performed with
> 'purge_props'
> > flag. If it's set to True, then all prop names, that are not included in
> > updated data, will be removed. In case of v2 we have to explicitly
> specify
> > prop names in the list param 'remove_props'. To implement this
> behaviour, if
> > 'purge_props' is set, we make additional 'get' request to determine the
> > existing properties and put in 'remove_prop' list only those, that are
> not
> > in updated_data.
> >
> > 6. My favourite:
> > There is an ability to activate an empty image by just providing 'size =
> 0':
> > https://review.openstack.org/#/c/9715/, in this case image will be a
> > collection of metadata. Glance v2 doesn't support this "feature" and
> that's
> > why we have to implement a very dirty workaround:
> > * v2 requires, that disk_format and container-format must be set
> before
> > the activation. if these params are not provided to 'create' method then
> we
> > hardcode it to 'qcow2' and 'bare'.
> > * we call 'upload' method with empty data (data = '') to activate
> image.
> > Me (and the rest glance team) think that this image activation with
> > zero-size is inconsistent and we won't implement it in v2. So, I'm going
> to
> > ask if Nova really needs this feature and maybe it's possible to make it
> > work without it.
>
> Nova uses this functionality when it creates snapshots of volume
> backed instances, that is, instances that only have Cinder volumes
> attached and do not have an ephemeral disk.
> In this case Nova API creates Cinder snapshots for the Cinder volumes
> and builds the block_device_mapping property with block devices that
> reference the Cinder snapshots.  Nova activates this image with size=0
> because this image does not have a disk and simply refers to the
> collection of Cinder snapshots that collectively comprise the binary
> image.  Callers of Glance outside of Nova may also use the APIs to
> create "block device mapping" images as well that contain references
> to Cinder volumes to attach, blank volumes to create, snapshots to
> create volumes from, etc during the server creation.  Not having the
> ability to create these images with V2 is a loss of function.
>
> The callers could supply 1 byte of junk data, like a space character,
> but that would result in a junk image being stored in Glance's default
> backing store for the image.  It would also give the impression that a
> real disk image exists for the image in a backing store which could be
> fetched, which is incorrect.
>
> If I remember correctly Glance V2 lets you transition an image from
> queued to active state with size = 0 if the image is using an external
> backing store such as http.  The store is then called to fetch the
> size.  Would it be possible to allow Glance to consider images with
> size = 0 and the block_device_mapping property to be "externally
> sourced" and allow the transition?
>
>
>
> >
> > In conclusion, I want to congratulate you with this huge progress and say
> > there is a big chance that we can deprecate glance v1 in 

Re: [openstack-dev] [doc] DocImpact vs. reno

2016-01-04 Thread Lana Brindley
I’m late to this party because holidays (Thanks Anne for bringing it to my 
attention).

First of all, sorry this came as a surprise. I tried hard to make sure everyone 
who needed to know knew, but that’s naturally a difficult thing to do.

To the implementation details: I really am struggling to see how Reno could be 
used as a DocImpact replacement, unless you’re going to use it to somehow 
enforce that packages with DocImpact include some kind of text file in the 
commit. That would be complete overkill, and has the potential to really mess 
up the development repos (who needs random text files littered around?). Maybe 
I’m missing something here, though.

Really, the intent of the job is merely to check for a description after the 
DocImpact tag that gives the docs people a hint as to what you were thinking 
when you added the tag. It’s simply a time saving measure on our part, and 
sometimes a thing that saves a large amount of human time needs to take a small 
amount of compute time. I don’t think that’s a big ask, but again, please 
correct me if I’m wrong.

In short, I would rather remove the DocImpact facility entirely than try and 
turn a tool designed for a completely different task to this problem. However, 
as this is the first complaint I’ve seen about this solution since starting 
working on this thorny problem nearly a year ago, I can’t help but wonder if 
we’re overreacting? Do people genuinely hate this solution enough that we need 
to go back to the drawing board?

Lana

> On 22 Dec 2015, at 10:33 AM, Doug Hellmann  wrote:
> 
> Excerpts from Andreas Jaeger's message of 2015-12-18 20:31:04 +0100:
>> On 12/18/2015 07:45 PM, Sean Dague wrote:
>>> On 12/18/2015 01:34 PM, Andreas Jaeger wrote:
 On 12/18/2015 07:03 PM, Sean Dague wrote:
> Recently noticed that a new job ended up on all nova changes that was
> theoertically processing commit messages for DocImpact. It appears to be
> part of this spec -
> http://specs.openstack.org/openstack/docs-specs/specs/mitaka/review-docimpact.html
> 
 
 Lana talked with John Garbutt about this and announced this also in
 several 'What's up' newsletters like
 http://lists.openstack.org/pipermail/openstack-dev/2015-December/081522.html
 
 
> First, a heads up would be good. Nova burns a lot of nodes (i.e. has a
> lot of patch volume), so this just decreased everyone's CI capacity
> noticably.
 
 I understand this reasoning and Joshua worked on a superior solution,
 see
 https://review.openstack.org/#/q/status:open+project:openstack-infra/zuul+branch:master+topic:skip-commit,n,z
 
 
> 
> Secondly, this all seems like the wrong direction. We've got reno now,
> which is extremely useful for documenting significant changes in the
> code base that need to be reflected up. We've dropped UpgradeImpact for
> an upgrade comment in reno, which is *so* much better.
> 
> It seems like using reno instead of commit message tags would be much
> better for everyone here.
 
 The goal of DocImpact is to notify the Documentation team about changes
 - currently done via bugs in launchpad so that manuals can be easily
 updated. How would this tracking work with docimpact?
>>> 
>>> Because the current concern seems to be that naked DocImpact tag leaves
>>> people guessing what is important. And I understand that. There is a
>>> whole job now to just check that DocImpact containts a reason after it.
>>> 
>>> We now have a very detailed system in reno to describe changes that will
>>> impact people using the code. It lets you do that with the commit and
>>> provide an arbitrarily large amount of content in it describing what and
>>> why you think that's important to reflect up.
>>> 
>>> I think it effectively deprecates all *Impact flags. Now we have a place
>>> for that payload.
>> 
>> 
>> We - Sean, Anne Gentle, and Jeremy Stanley - just discussed this on
>> #openstack-infra, let me summarize my understanding:
>> 
>> Some flags are used for checking before a merge the changes, especially
>> SecurityImpact and APIImpact. These are used for reviewing the changes.
>> This would be nice for DocImpact as well. SecurityImpact creates emails
>> for merged changes, DocImpact creates bugs for merged changes.
>> 
>> When the docimpact spec was written, reno was not in use - and later
>> nobody brought it up as alternative idea.
>> 
>> The idea going forward is instead of checking the commit message, is to
>> add a special section using reno that explains the changes that are
>> needed. A post-job would run and create bugs or sends out emails like
>> today whenever a new entry gets added. But this would be triggered by
>> special sections in the release-notes and not in the commit message. We
>> also expect/hope that release notes get a good review and thus the
>> quality of these notifications would be improved.
> 
> So you want to 

Re: [openstack-dev] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

2016-01-04 Thread Ihar Hrachyshka

Matthias Runge  wrote:


On Mon, Jan 04, 2016 at 12:29:27PM +0100, Ihar Hrachyshka wrote:

Matthias Runge  wrote:

testrepository

Any suggestions here?


Seems like pbr importing testrepository, hence the dependency belongs to
pbr, not horizon (and as a runtime dependency, not just test only).

But note that since pbr 1.1.0, they no longer depend on the package and  
fail

gracefully:

https://github.com/openstack-dev/pbr/commit/946cf80b750f3735a5d3b0c2173f4eaa7fad4a81

So the proper way would be indeed to make your package to install testr  
for

tests. Not sure why it worked before, but I would bet that some other
components installed it for you (devstack? devstack-gate? job definition?
some other component previously installed before keystone? Not that it’s  
too

important.)

Ihar


Thank you.

I'm a bit confused, why it worked before e.g Dec 20th last year, but
fails after.
And it's only failing in kilo, not on liberty.

And even when adding testrepository to test-requirements, it fails,
because it's missing?

If pbr uses testrepository at run-time, it should be pulled in as
run-time requirement.


Note that it’s keystone installation that fails, not horizon, and it seems  
that it’s for grenade (I see /opt/stack/new/keystone in the logs). I would  
expect keystone gate to be broken too, so you could add the dep there and  
validate whether it fixes the thing for you.


The best alternative outcome is probably to get a new ‘kilo’ (<1.0) pbr  
release that would pull in the dependency for you.


Ihar

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


Re: [openstack-dev] [devstack] [neutron] Procedure for back-porting a bug fix to stable/liberty branch of a Neutron script in DevStack?

2016-01-04 Thread Sean Dague
On 01/03/2016 09:23 PM, Kyle Mestery wrote:
> On Sun, Jan 3, 2016 at 5:22 PM, Mike Spreitzer  > wrote:
> 
> > From: Kyle Mestery >
> > To: "OpenStack Development Mailing List (not for usage questions)"
> >  >
> > Date: 01/03/2016 02:15 PM
> > Subject: Re: [openstack-dev] [devstack] [neutron] Procedure for
> > back-porting a bug fix to stable/liberty branch of a Neutron script
> > in DevStack?
> > 
> > On Sun, Jan 3, 2016 at 4:01 PM, Mike Spreitzer  > wrote:
> > I would like to back-port https://review.openstack.org/#/c/242721/
> > --- which fixed https://bugs.launchpad.net/devstack/+bug/1469596---
> > to stable/liberty.  I have contributed to main line development
> > before, but not stable branches.  I see that http://
> > docs.openstack.org/infra/manual/developers.htmldoes
>  not
> specifically
> > address this case.  What is the procedure to follow?
> 
> > The best place to look is in the project team guide [1],
> > specifically the section on proposing fixes.
> > 
> > [1] http://docs.openstack.org/project-team-guide/stable-branches.html
> > [2] http://docs.openstack.org/project-team-guide/stable-
> > branches.html#proposing-fixes
> 
> Regarding the mechanics, I was given the following alternate recipe
> in a discussion on #openstack-neutron; I assume it is pretty much
> equivalent.
> 
> "do something like 'git checkout -b libery/backport/###
> remotes/origin/stable/liberty' then 'git pull' then 'git review -X
> ###' then push it for review"
> 
> I think it is, but honestly, "git cherry-pick -x" is pretty simple as
> well and the way I've always done these.

Yeh, git cherry-pick -x is pretty much the way to go.

-Sean

-- 
Sean Dague
http://dague.net

__
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] The command "neutron-db-manage" of 8.0.0~b1 fails

2016-01-04 Thread Ihar Hrachyshka

Mike Bayer  wrote:




On 01/04/2016 06:59 AM, Ihar Hrachyshka wrote:

Martinx - ジェームズ  wrote:


Guys,

 I'm trying to experiment Mitaka on Ubuntu Xenial, which already have
beta version on its repositories, however, "neutron-db-manage" fails.

 Here is the output of it:

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

 Any clue?

 I'm using the Kilo instructions as a start point, of course, I'm
using new neutron.conf and new ml2_conf.ini as well.

Thanks in advance!
Thiago


I believe it was fixed in:
https://review.openstack.org/#/c/253150/2/neutron/db/migration/alembic_migrations/versions/mitaka/contract/8a6d8bdae39_migrate_neutron_resources_table.py


doh and I'm the one who fixed it!


Busy man you are.

Ihar

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


Re: [openstack-dev] [Horizon][stable][tempest] Horizon|tempest kilo gate fails due to testrepository dependency

2016-01-04 Thread Matthias Runge
On Mon, Jan 04, 2016 at 01:32:53PM +0100, Ihar Hrachyshka wrote:
> Note that it’s keystone installation that fails, not horizon, and it seems
> that it’s for grenade (I see /opt/stack/new/keystone in the logs). I would
> expect keystone gate to be broken too, so you could add the dep there and
> validate whether it fixes the thing for you.
> 
> The best alternative outcome is probably to get a new ‘kilo’ (<1.0) pbr
> release that would pull in the dependency for you.
> 

keystone fails after adding testrepository to horizons test
requirements.

Horizon failed before, if we don't add it. Horizon does not use testr at
all.
http://logs.openstack.org/periodic-stable/periodic-horizon-python27-kilo/3fc703b/tox/py27-2.log

It looks like keystone does not fail,
but tempest fails in the same way as horizon does:
http://logs.openstack.org/periodic-stable/periodic-tempest-dsvm-full-kilo/a33736f/logs/devstacklog.txt.gz
-- 
Matthias Runge 

__
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][Glance] Xenplugin + Glance_v2 = Hate

2016-01-04 Thread Sean Dague
On 12/24/2015 08:51 AM, Mikhail Fedosin wrote:
> Hello! As you may know there is a big initiative to adopt glance v2 api
> in Nova and the important part is making related changes in xenglugin.
> Unfortunately xenplugin doesn't use neither nova.image api nor
> glanceclient. Instead of this it has own http client implementation and
> bunch of hardcoded 'v1' urls (example,
> https://github.com/openstack/nova/blob/master/plugins/xenserver/xenapi/etc/xapi.d/plugins/glance#L130).
> It leads to the fact, that it will be really hard to switch it on v2 api
> right.
> 
> Personally I see 2 solutions:
> 1. Make xenplugin to adopt nova.image api, which will make it
> version-agnostic. Here it's not easy to implement and we won't be able
> to keep backward compatibility with the existing lowlevel code.
> 2. Also hardcode v2 urls on par with v1 and do the same thing as in
> nova.image - to determine current glance api version before request and
> then use appropriate urls in methods.
> 
> IMHO, the second solution is more preferable, because I understand how
> to do it and the v1/v2 compatibility will be 100%. It guarantees that we
> won't break any of existing deployments and it will allow to merge
> glance_v2 code in nova.image much quicker.
> 
> All opinions and advice will be very helpful. Thanks in advance!

So it is a little weird, but it's not as terrible as it could be.

The glance plugin is effectively an RPC interface from Nova proper. I
just had to bump it to make glance pass around urls instead of tuples -
https://review.openstack.org/#/c/254785/6/plugins/xenserver/xenapi/etc/xapi.d/plugins/glance

I would just add another set of calls in that glance plugin that use v2
instead of v1. Then let nova decide it's going to call v2 vs. v1 from
it's side.

As a bonus, having *some* testing added to this path would be great as
well. The xenserver glance plugins have no tests right now, and doing
something like v2 vs. v1 would be good to get something basic tested there.

-Sean

-- 
Sean Dague
http://dague.net

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


Re: [openstack-dev] [TripleO] Removing the Tuskar repos

2016-01-04 Thread Ryan Brown

On 12/22/2015 12:44 PM, Jason Rist wrote:

On 12/22/2015 04:38 AM, Dougal Matthews wrote:

Hi all,

I mentioned this at the meeting last week, but wanted to get wider input.
As far as I can tell from the current activity, there is no work going into
Tuskar and it isn't being tested with CI. This means the code is becoming
more stale quickly and likely wont work soon (if not already).

TripleO common is working towards solving the same problems that Tuskar
attempted and can be seen as the replacement for Tuskar. [1][2]

Are there any objections to it's removal? This would include the tuskar,
python-tuskarclient and tuskar-ui repos. We would also need to remove it
from instack-undercloud and tripleo-image-elements.

I'll start to beginning the cleanup process sometime in min/late January if
there are no objections.

Cheers,
Dougal


[1]:
https://specs.openstack.org/openstack/tripleo-specs/specs/mitaka/tripleo-overcloud-deployment-library.html
[2]: https://review.openstack.org/230432



__
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


+1


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

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


Re: [openstack-dev] [Trove][Outreachy] Add configuration groups for CouchDB

2016-01-04 Thread Victoria Martínez de la Cruz
Retaking this after the holidays.

If someone is working on this, please let us know. Otherwise, Sonali will
submit the spec for review by the end of this week.

Best,

Victoria

2015-12-22 13:05 GMT-03:00 Amrith Kumar :

> Victoria,
>
>
>
> As several people are now on holiday (and likely through the end of the
> year), you may not receive an answer either positive or otherwise before
> the New Year.
>
>
>
> Please take that into consideration in your project choice.
>
>
>
> -amrith
>
>
>
> *From:* Victoria Martínez de la Cruz [mailto:
> victo...@vmartinezdelacruz.com]
> *Sent:* Tuesday, December 22, 2015 9:21 AM
> *To:* OpenStack Development Mailing List <
> openstack-dev@lists.openstack.org>
> *Subject:* [openstack-dev] [Trove][Outreachy] Add configuration groups
> for CouchDB
>
>
>
> Hi all,
>
>
>
> For those who are not aware, we have 7 Outreachy interns [0] working on
> different projects on OpenStack since last Dec 7th.
>
>
>
> Sonali (sonali5) will be working with us on Trove and we have been trying
> to locate a task for her to work on during her internship.
>
>
>
> Before the internship was announced, one month before Tokyo summit, I
> proposed "Adding CRUD for CouchDB" as her internship idea [1], but it was
> not notified as it should so other contributors took started working on
> this task.
>
>
>
> To avoid this to happen again, I decided to send this email and ask if
> someone if working on "Add configuration groups for CouchDB".
>
>
>
> If its ok for Trove team, Sonali will be working on that.
>
>
>
> Please, let me know if this is not the case and we will look for a
> different task for her.
>
>
>
> Thanks,
>
>
>
> Victoria
>
>
>
> [0] https://www.gnome.org/outreachy/
>
> [1] https://wiki.openstack.org/wiki/Internship_ideas
>
>
>
> __
> 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] weekly meeting #65

2016-01-04 Thread Emilien Macchi
Hi and happy new year folks!

Tomorrow we will have our weekly meeting at UTC 1500.
Here is our agenda:
https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160105

Feel free to add more topics, reviews, bugs, as usual.

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] The command "neutron-db-manage" of 8.0.0~b1 fails

2016-01-04 Thread Mike Bayer


On 01/04/2016 06:59 AM, Ihar Hrachyshka wrote:
> Martinx - ジェームズ  wrote:
> 
>> Guys,
>>
>>  I'm trying to experiment Mitaka on Ubuntu Xenial, which already have
>> beta version on its repositories, however, "neutron-db-manage" fails.
>>
>>  Here is the output of it:
>>
>>  http://paste.openstack.org/show/482920/
>>
>>  Any clue?
>>
>>  I'm using the Kilo instructions as a start point, of course, I'm
>> using new neutron.conf and new ml2_conf.ini as well.
>>
>> Thanks in advance!
>> Thiago
> 
> I believe it was fixed in:
> https://review.openstack.org/#/c/253150/2/neutron/db/migration/alembic_migrations/versions/mitaka/contract/8a6d8bdae39_migrate_neutron_resources_table.py

doh and I'm the one who fixed it!



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

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


Re: [openstack-dev] [Horizon][stable][tempest] Horizon|tempest kilo gate fails due to testrepository dependency

2016-01-04 Thread Ihar Hrachyshka

Matthias Runge  wrote:


On Mon, Jan 04, 2016 at 01:32:53PM +0100, Ihar Hrachyshka wrote:

Note that it’s keystone installation that fails, not horizon, and it seems
that it’s for grenade (I see /opt/stack/new/keystone in the logs). I would
expect keystone gate to be broken too, so you could add the dep there and
validate whether it fixes the thing for you.

The best alternative outcome is probably to get a new ‘kilo’ (<1.0) pbr
release that would pull in the dependency for you.


keystone fails after adding testrepository to horizons test
requirements.


But have you tried to add the dep to keystone test reqs?

Ihar

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


Re: [openstack-dev] [nova][cinder] Deprecating ConfKeyManager (fixed-key key manager)

2016-01-04 Thread Sean Dague
On 12/30/2015 03:23 PM, Farr, Kaitlin M. wrote:
> All,
> 
> Please reply or send me an email if you are using the ConfKeyManager
> (fixed-key key manager) in deployment for volume encryption or
> ephemeral storage encryption. You can check this by looking at the
> [keymgr] section, api_class entry of nova.conf or cinder.conf. The
> ConfKeyManager was only intended for testing and I am working on
> deprecating it. I would like to gauge the number of people using
> that backend, because it may affect the deprecation strategy.
> 
> This is the start of the effort to replace the duplicated key manager
> code with Castellan [1], a key manager interface library that allows
> the user to swap out different backends, such as Barbican. While
> Castellan is based on the key managers built into Nova and Cinder, it
> does not have the fixed-key backend. That backend is insecure. A single
> key is used for all volumes. If the key is compromised, all of the
> encrypted data is easily decrypted. See Joel Coffman's comments on the
> Nova spec [2]. Deprecating the fixed-key key manager would need to
> occur before Castellan is integrated.
> 
> Again, please let me know if you use the ConfKeyManager and you
> actively use the volume encryption and encrypted cinder volume features
> in a deployment
> 
> Other feedback is also welcome.
> 
> I am also creating a separate thread with this info on the operators
> mailing list.
> 
> Thanks,
> 
> Kaitlin Farr
> 
> 1. Castellan source code. https://github.com/openstack/castellan
> 2. Castellan integration Nova spec. https://review.openstack.org/#/c/247561/
> 3. Castellan integration Cinder spec. https://review.openstack.org/#/c/247577/

The fixed key manager is useful for easy testing (we're using it in the
gate in places where barbican isn't available). Is there anything
equivalent with Catellan?

-Sean

-- 
Sean Dague
http://dague.net

__
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] The command "neutron-db-manage" of 8.0.0~b1 fails

2016-01-04 Thread Mike Bayer


On 01/03/2016 10:57 PM, Martinx - ジェームズ wrote:
> On 4 January 2016 at 01:28, Mike Bayer  wrote:
>>
>>
>> On 01/03/2016 05:15 PM, Martinx - ジェームズ wrote:
>>> Guys,
>>>
>>>  I'm trying to experiment Mitaka on Ubuntu Xenial, which already have
>>> beta version on its repositories, however, "neutron-db-manage" fails.
>>>
>>>  Here is the output of it:
>>>
>>>  http://paste.openstack.org/show/482920/
>>>
>>>  Any clue?
>>
>> this is a new error added to MySQL as of version 5.6.7:
>>
>> https://dev.mysql.com/doc/refman/5.6/en/error-messages-server.html#error_er_fk_column_cannot_change
>>
>> some discussion is at http://stackoverflow.com/a/17019351/34549.
>>
>> the issue here is either that the table contains NULL values or that the
>> BIGINT datatype is not compatible with the column to which the foreign
>> key refers.
>>
>> This error looks familiar but I don't recall if I saw it specific to
>> Neutron already having this issue before.
>>
> 
> Wow! Thank you! It is working now!
> 
> What I did?
> 
> 
> To turn off foreign key constraint globally, by running directly on
> MySQL root shell:
> 
> SET GLOBAL FOREIGN_KEY_CHECKS=0;
> 
> and remember to set it back when you are done... Then, neutron-db-manage 
> worked!
> 
> su -s /bin/sh -c "neutron-db-manage --config-file
> /etc/neutron/neutron.conf --config-file
> /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head" neutron
> 
> After that, I re-enabled foreign_key_checks:
> 
> SET GLOBAL FOREIGN_KEY_CHECKS=1;


the problem with doing this is that whatever invalid conditions exist
with this foreign key aren't checked.   probably OK in this case but as
a general approach, turning off FKs, while a popular solution on google,
should be avoided if possible.

> 
> Apparently, people will face this problem while trying Mitaka on
> Xenial... Isn't "neutron-db-manage" aware of this new feature /
> situation of MySQL 5.6?
> 
> Should I fill a bug report on Launchpad about this?
> 
> Continuing my tests now...   :-D
> 
> Thanks again!
> Thiago
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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


Re: [openstack-dev] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

2016-01-04 Thread Matthias Runge
On Mon, Jan 04, 2016 at 12:29:27PM +0100, Ihar Hrachyshka wrote:
> Matthias Runge  wrote:
> >testrepository
> >
> >Any suggestions here?
> 
> Seems like pbr importing testrepository, hence the dependency belongs to
> pbr, not horizon (and as a runtime dependency, not just test only).
> 
> But note that since pbr 1.1.0, they no longer depend on the package and fail
> gracefully:
> 
> https://github.com/openstack-dev/pbr/commit/946cf80b750f3735a5d3b0c2173f4eaa7fad4a81
> 
> So the proper way would be indeed to make your package to install testr for
> tests. Not sure why it worked before, but I would bet that some other
> components installed it for you (devstack? devstack-gate? job definition?
> some other component previously installed before keystone? Not that it’s too
> important.)
> 
> Ihar

Thank you.

I'm a bit confused, why it worked before e.g Dec 20th last year, but
fails after.
And it's only failing in kilo, not on liberty.

And even when adding testrepository to test-requirements, it fails,
because it's missing?

If pbr uses testrepository at run-time, it should be pulled in as
run-time requirement.
-- 
Matthias Runge 

__
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] [devstack][QA] Changing logging format to match documented defaults

2016-01-04 Thread Sean Dague
On 12/22/2015 01:55 PM, Ronald Bradford wrote:
> Hi All,
> 
> I have observed that devstack uses custom logging formatting that
> differs from the documented defaults. An example is for nova.
> 
> logging_context_format_string = %(asctime)s.%(msecs)03d %(levelname)s
> %(name)s [%(request_id)s *_%(user_name)s %(project_name)s_*]
> %(instance)s%(message)s
> 
> which is defined in [1] , compared with
> 
> logging_context_format_string = %(asctime)s.%(msecs)03d %(levelname)s
> %(name)s [%(request_id)s *_%(user_identity)s_*] %(instance)s%(message)s
> 
> which is the current Liberty specified default [2].  This infact is the
> Oslo Logging default value and then can effectively be not defined at all.
> 
> In my manual tests I see not see failures when changing this in nova,
> but as I know Infra and QA relies on devstack I would like to solicit
> feedback from team members before proposing any changes to bring these
> to being consistent.  This logging variable is also defined differently
> across 4 projects (nova, cinder, keystone and glance) so ultimately the
> goal would be to ensure they may present documented configuration defaults.
> 
> [1] http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/nova#n580
> [2]
> http://docs.openstack.org/liberty/config-reference/content/list-of-compute-config-options.html#config_table_nova_logging

Symbolic names instead of uuids are really needed to make any reasonable
sense of the logs by humans. The devstack overrides are probably better
defaults for the projects than their current defaults.

-Sean

-- 
Sean Dague
http://dague.net

__
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] [heat][telemetry] gate-ceilometer-dsvm-integration broken

2016-01-04 Thread Steven Hardy
On Mon, Jan 04, 2016 at 11:31:40AM +0100, Julien Danjou wrote:
> On Mon, Jan 04 2016, Steven Hardy wrote:
> 
> Hi,
> 
> > Firstly, I'm very sorry for the breakage here, and I agree that in general
> > a quick-revert is the best policy when something like this happens.
> 
> No problem Steven, shit happens.
> 
> It'd be even better if Heat'd move to a devstack plugin to limit this
> kind of high level latency. Just by curiosity, is there a plan for that?
> 
> > I'm a little unclear how this occurred tho, since I had a clear CI run on
> > this patch:
> >
> > https://review.openstack.org/#/c/256315/
> 
> I think the dsvm tests are not the same that we run on telemetry side:
> we run it with the Gnocchi backend, whereas you're likely using the
> (old) Ceilometer backend. And that's the Gnocchi backend that has been
> broken by the original devstack change from what I saw.
> 
> Maybe Heat should also run this job, WDYT?
> 
> > Given that the review latency on Devstack is quite high, it seems possible
> > we'll land (2) before (1) lands, but if not then I'll re-propose it and
> > hopefully figure out where I went wrong with Depends-On to confirm all is
> > fixed before it lands.
> 
> Yeah, whatever fixes the issue I'm ok with. :-) If you can fix Heat
> faster, that'd be even cooler.

Ok, so status update, the relevant Heat fixes have landed (thanks to
ramishra and huangtianhua for investigating/fixing!):

https://review.openstack.org/#/q/topic:bug/1529058

I've rechecked https://review.openstack.org/#/c/261923/1 which will
hopefully show the issue is resolved and the devstack revert can be
abandoned.

Thanks all for your patience while we worked this issue out.

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] [openstack][magnum]Create trustee user for each bay

2016-01-04 Thread Adam Young

On 12/24/2015 03:20 AM, 大塚元央 wrote:

Hi, Hua.

I agree with you if trust_id is secret.
But I think trust_id is not a secret.


This is not correct.  Trust ID is only usable by the trustee user to get 
a token, and does not need to be treated as a secret.


User can know trustee_user_name and trustee_password from k8s/swarm 
instances.
If user knows about other user's trust_id, user can use a other user's 
swift resources.

This wii be a security risk.
Thanks
-yuanying

2015年12月24日(木) 16:49 王华 >:


Hi all,

I want to create a trustee user for each bay [1]. The discussion
for trust is in [2].

Here is my solution:
I don't create a user for each bay. All the bays no matter who
creates it use the same user.
But we create different trust for the user for different bay. The
user can not access any service without the trust id. So there is
no need to create a user for each bay.



[1]https://blueprints.launchpad.net/magnum/+spec/create-trustee-user-for-each-bay
[2]https://review.openstack.org/#/c/254705/

Regards,
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



__
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] [Neutron][Dragonflow] - IRC Meeting Cancelled (1/11)

2016-01-04 Thread Gal Sagie
Hello All,

Just wanted to let everyone know that we wont have a Dragonflow IRC meeting
next week (Monday, 1/11)

We will continue with the meetings the week after (1/18)

Thanks
Gal.
__
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 SKIPPED, Tue January 5th, 21:00 UTC

2016-01-04 Thread Mike Perez
Hi all!

We will be skipping the cross-project meeting since there are no agenda items
to discuss, but someone can add one [1] to call a meeting next time.

We also have a new meeting channel which is #openstack-meeting-cp where the
cross-project meeting will now take place at it's usual time Tuesdays at 2100
UTC.


[1] - 
https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Proposed_agenda

-- 
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] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

2016-01-04 Thread Matthias Runge
On 04/01/16 15:41, Ihar Hrachyshka wrote:
> UPD: Turns out it breaks Liberty gate too, f.e. for Neutron. It’s
> interesting that it did not break the thing for e.g. Neutron master.
> 
> Matthias Runge  wrote:
> 
>> Hello,
>>

Horizon in Kilo *only* fails since Dec 26th. Horizon liberty seems to be
fine.

Matthias


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


Re: [openstack-dev] [nova][cinder] Deprecating ConfKeyManager (fixed-key key manager)

2016-01-04 Thread Farr, Kaitlin M.
> The fixed key manager is useful for easy testing (we're using it in the
> gate in places where barbican isn't available). Is there anything
> equivalent with Catellan?
> 
> -Sean
> 
> --
> Sean Dague
> http://dague.net

There is no fixed-key back end with Castellan. I agree that using a
fixed key makes for very easy testing, but the tests use a
configuration (ConfKeyManager) that should not be used in deployment.
The tests could be made much more useful if they used a more realistic
configuration (Barbican).

Adding a gate that tests using DevStack with Barbican enabled would
be a more valuable than the existing tests for two reasons:

 1. ConfKeyManager could be removed.
 2. It would test the feature configured more closely to how a
deployment would actually look.

As part of this change to deprecate ConfKeyManager and integrate
Castellan, I would like to add this new gate.

 -Kaitlin

__
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] Is "domain" a mapping to real-world cloud tenant?

2016-01-04 Thread Lance Bragstad
Interesting. The paper says that the implementation was based on the Havana
release. Just out of curiosity, does anyone know if the code is public?

On Mon, Dec 14, 2015 at 6:38 PM, darren wang 
wrote:

> Hi Dolph,
>
>
>
>  Here it is,
> http://profsandhu.com/confrnc/misconf/nss14-preprint-bo.pdf
>
>
>
>  You may have a look at it and see if it’s reasonable.
>
>
>
> Darren
>
>
>
> *发件人:* Dolph Mathews [mailto:dolph.math...@gmail.com]
> *发送时间:* 2015年12月15日 6:10
> *收件人:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *主题:* Re: [openstack-dev] [keystone] Is "domain" a mapping to real-world
> cloud tenant?
>
>
>
> Unfortunately, "tenancy" has multiple definitions in our world so let me
> try to clarify further! Do you have a link to that paper?
>
>
>
> Tenants (v2) and projects (v3) have a history as serving to isolate the
> resources (VMs, networks, etc) of multiple tenants. They literally provide
> for multitenancy.
>
>
>
> Domains exist at a higher level, and actually (unfortunately) serve a
> multiple purposes.
>
>
>
> The first of which is as a container for multiple tenants/projects - think
> of domains as the billable entity in a public cloud. A single domain might
> be responsible for deploying multiple department's or project's resources
> in the cloud (each of which requires multi-tenant isolation, and thus has
> many tenants/projects).
>
>
>
> The second purpose is that of authorization -- in keystone, you might need
> domain-level authorization to create projects and assign roles. The same
> might apply to domain-specific quotas, domain-specific policies, and other
> domain-level concerns.
>
>
>
> Lastly, domains serve as a namespaces for users and groups (identity /
> authentication) within keystone itself. They are analogous to identity
> providers in that regard.
>
>
>
> Hope this helps!
>
>
>
> On Mon, Dec 14, 2015 at 2:56 AM, darren wang 
> wrote:
>
> Hi,
>
>
>
> I am wondering whether “domain” is a mapping to a real-world cloud tenant
> (not the counterpart of “project” in v2 Identity API) because recently I
> read a paper that describes “domain” as a fit for the abstract concept “cloud
> tenant”. Does this saying stay in line with community’s purpose?
>
>
>
> 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
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

2016-01-04 Thread Ihar Hrachyshka
UPD: Turns out it breaks Liberty gate too, f.e. for Neutron. It’s  
interesting that it did not break the thing for e.g. Neutron master.


Matthias Runge  wrote:


Hello,

did we had a recent change in stable tests for Kilo?

Horizon tests for kilo are now failing due to a missing dependency to
testrepository. Horizon never used testrepository (until recently,
where I added testr support, but only in mitaka branch).

As a test, I added a test dependency for kilo branch, but that fails
somewhere else due to missing testrepository:

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

The error is in [1] somewhere at the bottom:

É5-12-30 09:53:27.883 | Obtaining file:///opt/stack/new/keystone
2015-12-30 09:53:28.504 | Complete output from command python
setup.py egg_info:
2015-12-30 09:53:28.504 | ERROR:root:Error parsing
2015-12-30 09:53:28.504 | Traceback (most recent call last):
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/core.py", line 109, in pbr
2015-12-30 09:53:28.504 | attrs = util.cfg_to_args(path)
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/util.py", line 261, in
cfg_to_args
2015-12-30 09:53:28.504 | wrap_commands(kwargs)
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/util.py", line 482, in
wrap_commands
2015-12-30 09:53:28.504 | for cmd, _ in dist.get_command_list():
2015-12-30 09:53:28.504 |   File
"/usr/local/lib/python2.7/dist-packages/setuptools/dist.py", line 446,
in get_command_list
2015-12-30 09:53:28.504 | cmdclass = ep.resolve()
2015-12-30 09:53:28.505 |   File
"/usr/local/lib/python2.7/dist-packages/pkg_resources/__init__.py", line
2386, in resolve
2015-12-30 09:53:28.505 | module = __import__(self.module_name,
fromlist=['__name__'], level=0)
2015-12-30 09:53:28.505 |   File
"/usr/local/lib/python2.7/dist-packages/pbr/testr_command.py", line 47,
in 
2015-12-30 09:53:28.505 | from testrepository import commands
2015-12-30 09:53:28.505 | ImportError: No module named
testrepository
2015-12-30 09:53:28.505 | error in setup command: Error parsing
/opt/stack/new/keystone/setup.cfg: ImportError: No module named
testrepository

Any suggestions here?

[1]
http://logs.openstack.org/96/262296/2/check/gate-tempest-dsvm-full/e47e5c6/logs/devstacklog.txt.gz
--
Matthias Runge 

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



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


Re: [openstack-dev] [Horizon][stable] Horizon kilo gate fails due to testrepository dependency

2016-01-04 Thread Michał Dulko
On 01/04/2016 03:41 PM, Ihar Hrachyshka wrote:
> UPD: Turns out it breaks Liberty gate too, f.e. for Neutron. It’s
> interesting that it did not break the thing for e.g. Neutron master.
>
> Matthias Runge  wrote:

We observe this on Cinder's stable/liberty in Grenade tests (e.g. [1])
and on stable/kilo in whole Tempest (e.g. [2]).

[1] https://review.openstack.org/#/c/262162/
[2] https://review.openstack.org/#/c/246646/

__
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] [api] - WSGI 2.0 Call for Interest

2016-01-04 Thread Hayes, Graham
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I saw this [0] float by in an IRC room this morning -
is this something the API WG / OpenStack should be thinking of
participating in?

0 - https://mail.python.org/pipermail/web-sig/2016-January/005357.html

- - Graham
- -- 
Graham Hayes


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

iQEcBAEBAgAGBQJWio+bAAoJEPRBUqpJBgIiIBQIAJ6YlqaasdRtvNE8pemNtDOC
Qz9iSdz3/ACKatuO4gb9HFn/W2tIesZOioCvXepVyLnYQVTbB411jHJJxPbKVCzX
yPGRCkl6B7UeK21/wxMLhISGBQgHIzKXgdFysozBC8makegMSdyF9Qx7EuJt8zdu
BgqfBDO6WUIXgEmbOmn0kmExGm8U1APIpPg35w7ge4F7BoYm8qmnLtmz1PerX0Sk
EPEBYN1kGZr8oEPFuuybiBBpirqlDwa9fEibenOmKNr237JkLD7PlZlucfk4c0fd
Z28c/YC4ClsXrd5HakHI2rkL2xZsv2JUCZsruEZhBQNuHY46h5vFfdw2apwgHUM=
=aBUd
-END PGP SIGNATURE-

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


Re: [openstack-dev] [openstack][glance] add new property to image

2016-01-04 Thread Ian Cordasco
On 12/31/15, 01:36, "suresh knv"  wrote:

>Hi,
>
>I am trying to run Openstack on ARM64 architecture. ARM64 architecture
>with KVM hypervisor needs  GIC version(generic interrupt controller)
>as a property for the image when we are creating/uploading an image. I
>would like to include this property in the glance code. I am new to
>glance, Can someone suggest me how to approach for this.
>
>
>Thanks
>Suresh KN V

Hi Suresh,

This mailing list is intended for discussion about developing OpenStack,
not developing things that integrate with OpenStack. In the future you'll
have better luck using Ask OpenStack or the #openstack channel IRC.

A quick Google search of how to set a property on an Image brings up
https://ask.openstack.org/en/question/82826/how-to-unsetremove-image-propre
ty/ which should help you.

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] The command "neutron-db-manage" of 8.0.0~b1 fails

2016-01-04 Thread Martinx - ジェームズ
On 4 January 2016 at 12:20, Ihar Hrachyshka  wrote:
> Mike Bayer  wrote:
>
>>
>>
>> On 01/04/2016 06:59 AM, Ihar Hrachyshka wrote:
>>>
>>> Martinx - ジェームズ  wrote:
>>>
 Guys,

  I'm trying to experiment Mitaka on Ubuntu Xenial, which already have
 beta version on its repositories, however, "neutron-db-manage" fails.

  Here is the output of it:

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

  Any clue?

  I'm using the Kilo instructions as a start point, of course, I'm
 using new neutron.conf and new ml2_conf.ini as well.

 Thanks in advance!
 Thiago
>>>
>>>
>>> I believe it was fixed in:
>>>
>>> https://review.openstack.org/#/c/253150/2/neutron/db/migration/alembic_migrations/versions/mitaka/contract/8a6d8bdae39_migrate_neutron_resources_table.py
>>
>>
>> doh and I'm the one who fixed it!
>
>
> Busy man you are.
>
>
> Ihar

LOL

AWESOME!

Thank you guys!

__
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][cinder] Deprecating ConfKeyManager (fixed-key key manager)

2016-01-04 Thread Eric Harney
On 01/04/2016 10:46 AM, Farr, Kaitlin M. wrote:
>> The fixed key manager is useful for easy testing (we're using it in the
>> gate in places where barbican isn't available). Is there anything
>> equivalent with Catellan?
>>
>> -Sean
>>
>> --
>> Sean Dague
>> http://dague.net
> 
> There is no fixed-key back end with Castellan. I agree that using a
> fixed key makes for very easy testing, but the tests use a
> configuration (ConfKeyManager) that should not be used in deployment.
> The tests could be made much more useful if they used a more realistic
> configuration (Barbican).
> 
> Adding a gate that tests using DevStack with Barbican enabled would
> be a more valuable than the existing tests for two reasons:
> 
>  1. ConfKeyManager could be removed.
>  2. It would test the feature configured more closely to how a
> deployment would actually look.
> 
> As part of this change to deprecate ConfKeyManager and integrate
> Castellan, I would like to add this new gate.
> 
>  -Kaitlin
> 

Aiming toward tests that mirror real-world deployment is certainly a
good thing, but I don't think we should remove ConfKeyManager.

We will want to maintain the ability to test these Cinder/Nova code
paths in development environments or in some automated environments
without requiring additional services to be configured.

We can address this by having ConfKeyManager emit warning messages
indicating that it isn't for production environments.

Thanks,
Eric


__
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] [Tacker] Next IRC weekly meeting - Jan 5th

2016-01-04 Thread Sridhar Ramaswamy
Tackers,

We will have our first weekly IRC meeting of 2016 this week on Tuesday Jan
5 @ UTC 1700 (our usual slot). Please find the agenda here,

https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_Jan_5.2C_2016

thanks,
Sridhar
__
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][cinder] Deprecating ConfKeyManager (fixed-key key manager)

2016-01-04 Thread Sean Dague
On 01/04/2016 11:03 AM, Eric Harney wrote:
> On 01/04/2016 10:46 AM, Farr, Kaitlin M. wrote:
>>> The fixed key manager is useful for easy testing (we're using it in the
>>> gate in places where barbican isn't available). Is there anything
>>> equivalent with Catellan?
>>>
>>> -Sean
>>>
>>> --
>>> Sean Dague
>>> http://dague.net
>>
>> There is no fixed-key back end with Castellan. I agree that using a
>> fixed key makes for very easy testing, but the tests use a
>> configuration (ConfKeyManager) that should not be used in deployment.
>> The tests could be made much more useful if they used a more realistic
>> configuration (Barbican).
>>
>> Adding a gate that tests using DevStack with Barbican enabled would
>> be a more valuable than the existing tests for two reasons:
>>
>>  1. ConfKeyManager could be removed.
>>  2. It would test the feature configured more closely to how a
>> deployment would actually look.
>>
>> As part of this change to deprecate ConfKeyManager and integrate
>> Castellan, I would like to add this new gate.
>>
>>  -Kaitlin
>>
> 
> Aiming toward tests that mirror real-world deployment is certainly a
> good thing, but I don't think we should remove ConfKeyManager.
> 
> We will want to maintain the ability to test these Cinder/Nova code
> paths in development environments or in some automated environments
> without requiring additional services to be configured.
> 
> We can address this by having ConfKeyManager emit warning messages
> indicating that it isn't for production environments.

Right, effectively the fixed key manager was a Testing Fixture for us.
That's really important because it reduces the number of moving parts
when testing this stuff as a full stack.

-Sean

-- 
Sean Dague
http://dague.net

__
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] [neutron] Serious bug in puppet neutron cli json output parsing.

2016-01-04 Thread Mike Dorman
I wonder if we should just refactor the Neutron provider to support either 
format?  That way we stay independent from whatever the particular 
installation’s cliff/tablib situation is.

We can probably safely assume that none of the Neutron objects will have 
attributes called ‘Field’ or ‘Value’, so it would be fairly easy to detect 
which format is there.

Mike


From: Denis Egorenko >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, December 31, 2015 at 5:59 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] [puppet] [neutron] Serious bug in puppet neutron 
cli json output parsing.

Last I checked, which was quite a while ago, openstackclient didn't support 
everything we were using from the neutron client.

That's true. Openstack client doesn't support all features of neutron client 
[1].

I would prefer use 3) option, but, unfortunately, i also don't see way, how to 
detect stevedore and cliff.

[1] 
https://github.com/openstack/python-openstackclient/blob/master/setup.cfg#L329-L339

2015-12-30 19:53 GMT+03:00 Colleen Murphy 
>:


On Wed, Dec 30, 2015 at 8:37 AM, Sofer Athlan-Guyot 
> wrote:
Hi,

I have added neutron people as they may help to find a solution.

After banging my head against the wall for a whole afternoon I
discovered a serious bug in puppet neutron module.

I not going to repeat here the detail of the bug report[1].  Basically:
 - neutron_port
 - neutron_subnet
 - neutron_router
 - neutron_network

may break idempotency randomly and won't work at all when clifftablib is
removed from the package dependency of python-openstackclient
(Mitaka[2])

So the problem is that neutron cli json output on liberty (at least, and
maybe before) is not consistent and may come from cliff or clifftablib.
I didn't test it but the same may apply to openstack cli. As we don't
use the openstack cli json output it's not a issue (for puppet modules)

The available solution I can see are:
 1. go back to parsing csv, shell output (revert [3])
 2. find a way to leverage openstacklib parsing for neutron as well
 3. keep json and parse the right output (cliff) and find a way to make
sure that it is always used by stevedore
 4. ?

Last I checked, which was quite a while ago, openstackclient didn't support 
everything we were using from the neutron client. I would like to reevaluate 
that and go with option 2 if we can. Otherwise option 1 seems reasonable.

From my point of view 3) is not a option, but other may disagree.

The problem is tricky and the fact that the CI cannot detect this is
trickier[4].

So before Mitaka, the json parsing should go.  I would love to see an
interface that all puppet modules would use (solution 2).  The current
openstacklib parses openstack client well enough.  The neutron command
is not that different and I think there is space for code reuse.  This
would be a long term solution.  It would bring the advantage of having
only one interface to change if it was decided to use the API directly
for instance[5]

In the meantime, a quick solution to this bug must be found.

Looking forward to your comments.

Regards,

[1] https://bugs.launchpad.net/puppet-neutron/+bug/1530163
[2] https://bugs.launchpad.net/python-neutronclient/+bug/1529914
[3] https://review.openstack.org/#/c/238156/
[4] https://review.openstack.org/#/c/262223/
[5] http://lists.openstack.org/pipermail/openstack-dev/2015-October/076439.html
--
Sofer Athlan-Guyot

Colleen

__
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,
Egorenko Denis,
Deployment Engineer
Mirantis
__
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] [neutron] [oslo] [cliff] Serious bug in puppet neutron cli json output parsing.

2016-01-04 Thread Akihiro Motoki
I added 'oslo' and 'cliff' subject tag as well.

2015-12-31 1:37 GMT+09:00 Sofer Athlan-Guyot :
> Hi,
>
> I have added neutron people as they may help to find a solution.
>
> After banging my head against the wall for a whole afternoon I
> discovered a serious bug in puppet neutron module.
>
> I not going to repeat here the detail of the bug report[1].  Basically:
>  - neutron_port
>  - neutron_subnet
>  - neutron_router
>  - neutron_network
>
> may break idempotency randomly and won't work at all when clifftablib is
> removed from the package dependency of python-openstackclient
> (Mitaka[2])
>
> So the problem is that neutron cli json output on liberty (at least, and
> maybe before) is not consistent and may come from cliff or clifftablib.
> I didn't test it but the same may apply to openstack cli. As we don't
> use the openstack cli json output it's not a issue (for puppet modules)

Apparently the problem comes from the fact the JSON output from
cliff 1.15.0 and cliff-tablib are different.

Another tricky point is that we have two entry points with a single name.
If we install cliff 1.15.0 and cliff-tablib, we will see two json and two yaml
formatters in the help message

> The available solution I can see are:
>  1. go back to parsing csv, shell output (revert [3])
>  2. find a way to leverage openstacklib parsing for neutron as well
>  3. keep json and parse the right output (cliff) and find a way to make
> sure that it is always used by stevedore
>  4. ?

A variation of option 3 is to release a new version of cliff-tablbi
without  json and yaml formatter.
cliff 1.15.0 and later supports JSON and YAML formatters,
so there is no need that cliff-tablib supports them.

When cliff 1.14.0 is used in some distribution, we can use the current version
of cliff-tablib. If someone uses the latest versions, he can use cliff
1.15.0 and
a new cliff-tablib without json and yaml formatters.
I believe it helps this confusing situation in liberty.

> From my point of view 3) is not a option, but other may disagree.

My vote is option 3. cliff (or neutronclient as workaround) can ensure
that either of cliff json formatter is chosen if two json formatters
are available.
However, I don't think it is a good idea that neutronclient cannot
provide cliff-tablib version
of JSON formatter if cliff 1.15.0 is installed.
Can puppet-neutron can handle the difference?

Akihiro

>
> The problem is tricky and the fact that the CI cannot detect this is
> trickier[4].
>
> So before Mitaka, the json parsing should go.  I would love to see an
> interface that all puppet modules would use (solution 2).  The current
> openstacklib parses openstack client well enough.  The neutron command
> is not that different and I think there is space for code reuse.  This
> would be a long term solution.  It would bring the advantage of having
> only one interface to change if it was decided to use the API directly
> for instance[5]
>
> In the meantime, a quick solution to this bug must be found.
>
> Looking forward to your comments.
>
> Regards,
>
> [1] https://bugs.launchpad.net/puppet-neutron/+bug/1530163
> [2] https://bugs.launchpad.net/python-neutronclient/+bug/1529914
> [3] https://review.openstack.org/#/c/238156/
> [4] https://review.openstack.org/#/c/262223/
> [5] 
> http://lists.openstack.org/pipermail/openstack-dev/2015-October/076439.html
> --
> Sofer Athlan-Guyot
>
> __
> 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] [kolla] Kolla Midcycle Dates

2016-01-04 Thread Steven Dake (stdake)
Hey folks,

A heads up the voting is in, and he only date that had no conflicts was  
(Tuesday) 2/9/16 and (Wednesday) 2/10/16.  I would recommend booking flights 
and hotels asap to cut down on costs.  Within 14 days of travel, flight costs 
increase dramatically which is around January 25th.

Later today after I have finished creating the midcycle wiki page, I will send 
a link with relevant information about the midcycle.

Just as a reminder for folks that want to get a head start on booking, the 
address of the midcycle venue is:

Bank of America Bldg (floor 3)
101 N Main St, Greenville, SC 29601

I'll post the Wiki information later today with full details.

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-dev] [ironic] weekly subteam status report

2016-01-04 Thread Ruby Loo
Hi,

We are amazed to present this week's subteam report for Ironic. As usual,
this is pulled directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
- Stats (diff with 21.12.2015):
- Ironic: 151 bugs (+8) + 149 wishlist items. 23 new (+5), 92 in progress
(+1), 0 critical, 14 high and 9 incomplete
- Inspector: 15 bugs (+3) + 15 wishlist items (+1). 0 new, 5 in progress, 1
critical (+1), 7 high and 0 incomplete
- Nova bugs with Ironic tag: 26. 1 new, 0 critical, 0 high

Network isolation (Neutron/Ironic work) (jroll)
===
- patches under review

Live upgrades (lucasagomes, lintan)
===
- patches ready to review:
- https://review.openstack.org/#/q/topic:refactor-object-registry
- https://review.openstack.org/#/q/topic:bp/online-upgrade-support

Inspector (dtansur)
===
- gate is broken again by ironic's move to a plugin:
https://bugs.launchpad.net/devstack/+bug/1530675 :(
- fix is approved

webclient (krotscheck / betherly)
=
- plugin:
- the plugin is in a slight limbo position waiting to see if someone
will send me through work on converting the panel to plugin (we split the
work and then she left her job) - hopefully i wont have to redo that
section :’(
- on a happier note we are well on the way to the ironic plugin project
being official in openstack and ready to start pushing things up
- webclient
- Intel is working on the UI trying to finish-up user research
- been a little pushback from intel UX on "Hey why does this look like
horizon"
- The ironic-webclient will permit significant changes to the UI
from the horizon base template, IF those changes do not compromise code
reuse.
- (This basically means that nothing in the ./src/api/--.js may
be modified, but that's really only API abstractions).

.

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] [Neutron] Gate failure

2016-01-04 Thread Armando M.
Hi folks,

Due to [1], Neutron related jobs (api, and lbaas) are failing. Please hold
your +A button until the issue is resolved.

Thanks,
Armando

[1] https://review.openstack.org/#/c/256164/
__
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] [api] - WSGI 2.0 Call for Interest

2016-01-04 Thread Ian Cordasco
On 1/4/16, 09:28, "Hayes, Graham"  wrote:

>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>I saw this [0] float by in an IRC room this morning -
>is this something the API WG / OpenStack should be thinking of
>participating in?
>
>0 - https://mail.python.org/pipermail/web-sig/2016-January/005357.html
>
>- - Graham
>- -- 
>Graham Hayes
>
>
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v2.0.22 (GNU/Linux)
>
>iQEcBAEBAgAGBQJWio+bAAoJEPRBUqpJBgIiIBQIAJ6YlqaasdRtvNE8pemNtDOC
>Qz9iSdz3/ACKatuO4gb9HFn/W2tIesZOioCvXepVyLnYQVTbB411jHJJxPbKVCzX
>yPGRCkl6B7UeK21/wxMLhISGBQgHIzKXgdFysozBC8makegMSdyF9Qx7EuJt8zdu
>BgqfBDO6WUIXgEmbOmn0kmExGm8U1APIpPg35w7ge4F7BoYm8qmnLtmz1PerX0Sk
>EPEBYN1kGZr8oEPFuuybiBBpirqlDwa9fEibenOmKNr237JkLD7PlZlucfk4c0fd
>Z28c/YC4ClsXrd5HakHI2rkL2xZsv2JUCZsruEZhBQNuHY46h5vFfdw2apwgHUM=
>=aBUd
>-END PGP SIGNATURE-

Tl;dr: The API Working Group, no. OpenStack *maybe*.


The API Working Group is focused on API design and consistency in
OpenStack APIs. WSGI is not something that the Working Group concerns
itself with.

OpenStack uses webob and other frameworks that are thin wrappers atop WSGI
and might be interested in it. That discussion, however, talks about
retaining easy compatibility with HTTP/1.x which is likely where OpenStack
will stay for the foreseeable future. Most of the benefits of HTTP/2 may
not be something OpenStack will care about for a while. So while OpenStack
may not be concerned with the HTTP/2 portion of WSGI 2.0 they may be
concerned with fixing bugs produced by design decisions and contributing
use-cases/feedback on proposed designs.

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] [nova][cinder] Deprecating ConfKeyManager (fixed-key key manager)

2016-01-04 Thread Matt Riedemann



On 1/4/2016 10:03 AM, Eric Harney wrote:

On 01/04/2016 10:46 AM, Farr, Kaitlin M. wrote:

The fixed key manager is useful for easy testing (we're using it in the
gate in places where barbican isn't available). Is there anything
equivalent with Catellan?

 -Sean

--
Sean Dague
http://dague.net


There is no fixed-key back end with Castellan. I agree that using a
fixed key makes for very easy testing, but the tests use a
configuration (ConfKeyManager) that should not be used in deployment.
The tests could be made much more useful if they used a more realistic
configuration (Barbican).

Adding a gate that tests using DevStack with Barbican enabled would
be a more valuable than the existing tests for two reasons:

  1. ConfKeyManager could be removed.
  2. It would test the feature configured more closely to how a
 deployment would actually look.

As part of this change to deprecate ConfKeyManager and integrate
Castellan, I would like to add this new gate.

  -Kaitlin



Aiming toward tests that mirror real-world deployment is certainly a
good thing, but I don't think we should remove ConfKeyManager.

We will want to maintain the ability to test these Cinder/Nova code
paths in development environments or in some automated environments
without requiring additional services to be configured.

We can address this by having ConfKeyManager emit warning messages
indicating that it isn't for production environments.

Thanks,
Eric


__
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



Note that at least in nova, the single key manager already emits a 
warning when used [1].


[1] 
https://github.com/openstack/nova/commit/97d63d8745cd9b3b391ce96b94b4da263b3a053d#L40


--

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] [Nova] live migration meeting

2016-01-04 Thread Murray, Paul (HP Cloud)
Hi All,

The first live migration meeting of the year will be tomorrow - see the meeting 
page: https://wiki.openstack.org/wiki/Meetings/NovaLiveMigration

Agenda on the page, feel free to add.

Happy New Year,
Paul

Paul Murray
Technical Lead, HPE Cloud
Hewlett Packard Enterprise
+44 117 316 2527


__
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