Re: [openstack-dev] [Congress] Mid-cycle sprint
Hi Zhou, The requirements for the request_refresh API call came from a customer. It wasn't intended as a replacement for the functionality we'd get by integrating with oslo.messaging. But it was a simple feature to add, with nice properties from Congress's perspective, driven by a real use case. It'd be great to support a more standard kind of streaming as well, such as with oslo.messaging. Tim On Thu, Jun 18, 2015 at 11:10 PM Zhou, Zhenzan zhenzan.z...@intel.com wrote: Hi, Tim I have looked at the request_fresh_action. One big question is that it requires external services to queue up changes and then call this Congress API at some point. I’m not sure they would buy in this design as many projects have notification mechanism ready now and Ceilometer heavily depends on these notifications. So basically I prefer to use oslo.messaging. But this API is still useful for other external services that don’t use oslo.messaging notification to publish changes and are willing to integrate with Congress this way. Anyway, I can upload my draft bp for review at first. Thanks. BR Zhou Zhenzan *From:* Tim Hinrichs [mailto:t...@styra.com] *Sent:* Wednesday, June 17, 2015 21:57 *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Congress] Mid-cycle sprint Hi Zhenzan, Yes the oslo.messaging integration task is relevant--oslo.messaging is one way of achieving cross-process, cross-host messaging. So I'll count you as interested for the mid-cycle sprint. Have you looked at the API call that forces a datasource driver to pull immediately? See congress/api/datasource_model.py:DatasourceModel.request_refresh_action. We had envisioned using that to implement a kind of notification from external services as follows. The external service queues up a list of changes and when the queue is long enough runs the API call to force the datasource driver hooked up to that service to pull those changes and then publish them on the bus. So it's not exactly streaming updates from the external service (which is good so that Congress can easily rate-limit updates), but it has almost the same effect. Tim On Tue, Jun 16, 2015 at 6:02 PM Zhou, Zhenzan zhenzan.z...@intel.com wrote: Hi, Tim Is this the oslo.messaging integration task? I’m interested in participating. Actually I am working on a bp to receive notifications from external services in datasource driver at first. I’m ok to change if the direction is to integrate oslo.messaging thoroughly (even replacing DSE). Thanks. BR Zhou Zhenzan *From:* Tim Hinrichs [mailto:t...@styra.com] *Sent:* Wednesday, June 17, 2015 05:14 *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* [openstack-dev] [Congress] Mid-cycle sprint Hi all, In the last couple of IRCs we've been talking about running a mid-cycle sprint focused on enabling our message bus to span multiple processes and multiple hosts. The message bus is what allows the Congress policy engine to communicate with the Congress wrappers around external services like Nova, Neutron. This cross-process, cross-host message bus is the platform we'll use to build version 2.0 of our distributed architecture. If you're interested in participating, drop me a note. Once we know who's interested we'll work out date/time/location details. Thanks! Tim __ OpenStack Development Mailing 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] [Neutron] Proposing Rossella Sblendido for the Control Plane core team
It's been a week with no negative feedback. Welcome to the team Rossella! On Mon, Jun 15, 2015 at 2:53 AM, Oleg Bondarev obonda...@mirantis.com wrote: +1 On Mon, Jun 15, 2015 at 12:14 PM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 No doubt +1. On 06/12/2015 09:44 PM, Kevin Benton wrote: Hello! As the Lieutenant of the built-in control plane[1], I would like Rossella Sblendido to be a member of the control plane core reviewer team. Her review stats are in line with other cores[2] and her feedback on patches related to the agents has been great. Additionally, she has been working quite a bit on the blueprint to restructure the L2 agent code so she is very familiar with the agent code and the APIs it leverages. Existing cores that have spent time working on the reference implementation (agents and AMQP code), please vote +1/-1 for her addition to the team. Aaron, Gary, Assaf, Maru, Kyle, Armando, Carl and Oleg; you have all been reviewing things in these areas recently so I would like to hear from you specifically. 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.ht ml#core-review-hierarchy http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy 2. http://stackalytics.com/report/contribution/neutron-group/30 Cheers -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVfpdmAAoJEC5aWaUY1u574skIAOm15mNKujH3X3XSpwtmy+V4 cWNvjYZy0lCG2lbyAwGwgQD0Ybs88/RKOZPPpu9gugAuWcFQRHMSMcsahaTLcH5B 6imK0tEUUn2HdCd9522kEWtf7Hkpux6p5TLQQo2tucvIBQohJuU42EidfKs9Peat ed/2kiXm+TGRSnZHAYwzJIrttux3ntTLQeTvElo+4vUQEQJNwm8eguXiAPENEjr9 7Ou3TgnYeLXsfVopHXNV+jtkHDr92giB4joODqwc8RNDKE2+dhaqDxCrXq6ksYq7 RFiyVy1qve394ebP0Ta0dq6LKmAYZCnRC9i928GSK5RvQBvcnJRiyFGIgtn4Qu0= =59av -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Proposing Brian Haley to Neutron L3 Core Reviewer Team
Thanks for all the support, looking forward to helping out more :) -Brian On 06/18/2015 07:34 AM, Paul Michali wrote: Congratulations Brian! Great addition to the L3 team! On Wed, Jun 17, 2015 at 11:14 PM Edgar Magana edgar.mag...@workday.com mailto:edgar.mag...@workday.com wrote: Congratulations Brian! Welcome to the team! Edgar On 6/17/15, 3:59 PM, Carl Baldwin c...@ecbaldwin.net mailto:c...@ecbaldwin.net wrote: It has been a week and feedback has been positive and supportive of Brian's nomination. Welcome to the L3 core reviewer team, Brian. Carl On Wed, Jun 10, 2015 at 1:11 PM, Carl Baldwin c...@ecbaldwin.net mailto:c...@ecbaldwin.net wrote: Folks, As the Neutron L3 Lieutenant [1] under the PTL, Kyle, I'd like to propose Brian Haley as a member of the Neutron L3 core reviewer team. Brian has been a long time contributor in Neutron showing expertise particularly in IPv6, iptables, and Linux kernel matters. His knowledge and involvement will be very important especially in this area. Brian has become a trusted member of our community. His review stats [2][3][4] place him comfortably with other Neutron core reviewers. He regularly runs proposed patches himself and gives insightful feedback. He has shown a lot of interest in the success of Neutron. Existing Neutron core reviewers from the L3 area of focus, please vote +1/-1 for the addition of Brian to the core reviewer team. Specifically, I'm looking for votes from Henry, Assaf, and Mark. Thanks! Carl [1] http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers [2] https://review.openstack.org/#/q/reviewer:%22Brian+Haley+%253Cbrian.haley%2540hp.com%253E%22,n,z [3] http://stackalytics.com/report/contribution/neutron-group/90 [4] http://stackalytics.com/?user_id=brian-haleymetric=marks __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing 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] Angular dependencies and the hz.dashboard namespace
The Adding Angular Identity Dashboard[1] patch exposed an issue I saw previously that worried me[2]. I believe during recent Horizon work the concept of angular module namespaces and dependencies have been conflated. There's this idea that if you create a submodule inside a module namespace you *must* have that module depend on that submodule. I believe that is incorrect - just look at the angular codebase itself, and how it is used. If you want the ngCookies module in a couple of places then you have those modules depend on ngCookies (or, more likely, you just add it as a dependency to the app). The point is it's not just added automatically to the ng module as a dependency. If you need to use a module's functionality, you depend on the module. You don't just have all your modules *automatically* pulled in as dependencies. I have proposed a patch to remedy this for the existing optional[3] project dashboard[4]. I believe it is unnecessary to add extension of the hz.dashboard dependency list[5] since we already have an extensible dependency list for the application itself (which the hz.dashboard dependency list just extends). To answer the question explicitly raised what is the point of having the hz.dashboard module if it has no dependencies? It does two things: it defines the namespace in a formal manner (by itself unnecessary, but it's still nice to do) and it defines a constant which is used by other code. Eventually it may define more. There is an important difference between Python modules and Angular modules here - using a Python module like hz.dashboard in this way could cause problems because of the way Python sub-module namespaces and import ordering work. Angular's modules work very differently, and are not burdened by the same issues. In Python that constant would most likely have to be pushed out to a sub-module to avoid import loops. Richard [1] https://review.openstack.org/190852 [2] https://bugs.launchpad.net/horizon/+bug/1466713 [3] There may be other issues that prevent the project dashboard being optional - there are dependencies in Python-land from the admin dashboard hard-coded over to the project dashboard, for example. It might be a good idea to remedy that, since I think it probably exposes some other structural issues in the plugin mechanism we're providing to deployers. [4] https://review.openstack.org/#/c/193401/ [5] https://review.openstack.org/193671 __ OpenStack Development Mailing 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] (officially) deprecate stable/{grizzly, havana} branches
I'd vote for stable -2. I think a number of people do an upgrade maybe once a year. I believe CERN just upgraded to juno recently. On Tue, Jun 16, 2015 at 1:36 PM, Richard Raseley rich...@raseley.com wrote: Matt Fischer wrote: +1 from me for deprecation. I'd also like to know or have an official policy for future deprecations, such as when will we deprecate Icehouse? On Tue, Jun 16, 2015 at 9:50 AM, Emilien Macchi emil...@redhat.com mailto:emil...@redhat.com wrote: Hi, Some of our modules have stable/grizzly and stable/havana branches. Some of them have the CI broken due to rspec issues that would require some investigation and time if we wanted to fix it. We would like to know who plan to backport some patches in these branches? If nobody plans to do that, we will let the branches as they are now but won't officially support them. By support I mean maintaining the CI jobs green (rspec, syntax, etc), fixing bugs and adding new features. Any feedback is welcome! Regards, -- Emilien Macchi I echo your +1. Perhaps most current stable supported, -1 stable version? In that example, once the Liberty release of modules (or a particular module) is cut we would support Liberty and Kilo. When the same happens for M, we would deprecate Kilo and support M and Liberty. Stable -2 also seems sane - I don't have a good sense of how far people are generally behind. __ OpenStack Development Mailing 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] [api] [all] To changes-since or not to changes-since
From: Chris Dent chd...@redhat.com Sent: Friday, June 19, 2015 4:07 AM To: OpenStack-dev@lists.openstack.org Subject: [openstack-dev] [api] [all] To changes-since or not to changes-since There's an open question in the API-WG on whether to formalize or otherwise enshrine the concept of a changes-since query parameter on collection oriented resources across the projects. The original source of this concept is from Nova's API: http://docs.openstack.org/developer/nova/v2/polling_changes-since_parameter.html There are arguments for and against but we've been unable to reach a consensus so the agreed next step was to bring the issue to the mailing list so more people can hash it out and provide their input. The hope is that concerns or constraints that those in the group are not aware of will be revealed and a better decision will be reached. The basic idea of changes-since is that it can be used as a way to signal that the requestor is doing some polling and would like to ask Give me stuff that has changed since the last time I checked. As I understand it, for the current implementations (in Nova and Glance) this means including stuff that has been deleted. Repeated requests to the resource with a changes-since parameter gives a running report on the evolving state of the resource. This is intended to allow efficient polling[0]. The pro camp on this likes it because this is very useful and quite humane: The requestor doesn't need to know the details of how the query is is implemented under the hood. That is, if there are several timestamps associated with the singular resources in the collection which of those are used for time comparison and which attributes (such as state with a value of deleted) are used to determine if a singular resource is included. The service gets to decide these things and in order for efficient polling to actually be achieved it needs to do in order to make effective queries of the data store. The con camp doesn't like it because it introduces magic, ambiguity and inconsistency into the API (when viewed from a cross-project perspective) and one of the defining goals of the working group is to slowly guide things to some measure of consistency. The alternate approach is to formulate a fairly rigorous query system for both filtering[1] and sorting[2] and use that to specify explicit queries that state I want resources that are newer than time X in timestamp attribute 'updated_at' _and_ have attribute 'state' that is one of 'foo', 'bar' or 'baz'. I am wondering what are the reasons that changes-since seems to introduce magic, ambiguity and inconsistency into the API? Could this be addressed by requiring each service to precisely define what resources would be returned in response to the changes-since query? If each service defines this contract then there should not be any ambiguity on what resources to expect in the response of the query. That said, we may need to precisely define semantics of what it means to correctly implement this feature. For instance, could we define that the set of resources once returned by a particular timestamp in the query would be guaranteed to remain same for subsequent executions of the query (idempotency argument)? This may be difficult to ensure in systems that may be built around providing eventual guarantees. - Devdatta __ OpenStack Development Mailing 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] [qpid] [zmq] [RabbitMQ] [oslo] Pending deprecation of driver(s).
Excerpts from Ken Giusti's message of 2015-06-19 08:01:46 -0700: On Fri, Jun 19, 2015 at 2:15 AM Flavio Percoco fla...@redhat.com wrote: On 18/06/15 16:37 -0400, Doug Hellmann wrote: Excerpts from Clint Byrum's message of 2015-06-18 12:47:21 -0700: Hello! I know there's been a lot of churn and misunderstanding over the recent devstack changes, so I wanted to make it clear where we're going with messaging drivers now that the policy [1] was approved. According to the policy, drivers need to have at least 60% unit test coverage, and an integration test suite with at least 3 popular OpenStack projects, with preference for Nova, Cinder, and Glance, and individuals who will support said test suite. So, with that, the following is the status of each driver in tree right now: rabbit - 89% Unit test coverage. Being the default in devstack, and the default in nearly every project's config files, this one is heavily integration tested. There are multiple individuals who have proven to be able to debug failures related to RabbitMQ and are well known in the community. +1 qpid - Unit test coverage is at 77%, so it passes that bar. I cannot find any integration testing being done, so it fails that. I also have not found anyone who will step up and support it. So this should be deprecated immediately. +1 - I believe Ken and the other folks interested in this indicated that the AMQP 1.0 driver should replace this one. The qpid driver should be deprecated, I'll be doing so in the next couple of days. Look forward to the patch. +1 Speaking of AMQP 1.0, you don't mention that one (it uses qpid, but is separate from the driver named qpid). I'd like to clarify something about the AMQP 1.0 driver. It's not a direct replacement for the qpidd one because it uses an entirely different protocol that recently became a standard. The reason I mention this is because it doesn't really require qpidd - not the double d - which is the broker daemon in the qpid family. I guess the confusion comes because the library it sits on top off is called qpid-proton. The qpid family is a set of tools that provide messaging capabilities. Among those you find qpidd (broker daemon), qpid-proton (amqp1.0 library), qpid-dispatch (message router). It's confusing indeed. The importance of this distinction is that the amqp1.0 driver in oslo.messaging is intended as a protocol based driver and not targetting any technology. That is to say, that it could be written using a library that is not qpid-proton and it can talk to any message router or message broker that has support for amqp 1.0. +1 - yeah, we really shouldn't be considering the amqp1 driver as simply the replacement qpid driver - as Flavio points out it has the potential to provide compatibility with other messaging back ends. Clint - can you also include separate metrics for the amqp1 driver? It's far less clear to me how to measure the unit test coverage of the amqp driver. I'll wait for Flavio's answer to my question about where the code lives, because it is definitely not organized like the others. __ OpenStack Development Mailing 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] [qpid] [zmq] [RabbitMQ] [oslo] Pending deprecation of driver(s).
Excerpts from Flavio Percoco's message of 2015-06-18 23:14:49 -0700: On 18/06/15 16:37 -0400, Doug Hellmann wrote: Excerpts from Clint Byrum's message of 2015-06-18 12:47:21 -0700: Hello! I know there's been a lot of churn and misunderstanding over the recent devstack changes, so I wanted to make it clear where we're going with messaging drivers now that the policy [1] was approved. According to the policy, drivers need to have at least 60% unit test coverage, and an integration test suite with at least 3 popular OpenStack projects, with preference for Nova, Cinder, and Glance, and individuals who will support said test suite. So, with that, the following is the status of each driver in tree right now: rabbit - 89% Unit test coverage. Being the default in devstack, and the default in nearly every project's config files, this one is heavily integration tested. There are multiple individuals who have proven to be able to debug failures related to RabbitMQ and are well known in the community. +1 qpid - Unit test coverage is at 77%, so it passes that bar. I cannot find any integration testing being done, so it fails that. I also have not found anyone who will step up and support it. So this should be deprecated immediately. +1 - I believe Ken and the other folks interested in this indicated that the AMQP 1.0 driver should replace this one. The qpid driver should be deprecated, I'll be doing so in the next couple of days. Look forward to the patch. Speaking of AMQP 1.0, you don't mention that one (it uses qpid, but is separate from the driver named qpid). I'd like to clarify something about the AMQP 1.0 driver. It's not a direct replacement for the qpidd one because it uses an entirely different protocol that recently became a standard. Could you clarify where the code actually is, or more specifically, why the code doesn't follow the same organization as the others? There's no impl_amqp and the tests don't live in tests/drivers, but in tests/test_amqp_driver. I left it out because I didn't realize this new driver lived in tree. Anyway, this driver appears to land in the prospective drivers category in the spec. We failed to call out drivers that are still considered experimental, however I kind of feel like the driver should be out of tree until such time as it is usable enough that it _could_ have an integration test. So, is it feasible that this driver will fall in-line with the others in the next 6 months, or should we be looking at either revising the policy, or moving it out of tree until it is capable of that? The reason I mention this is because it doesn't really require qpidd - not the double d - which is the broker daemon in the qpid family. I guess the confusion comes because the library it sits on top off is called qpid-proton. The qpid family is a set of tools that provide messaging capabilities. Among those you find qpidd (broker daemon), qpid-proton (amqp1.0 library), qpid-dispatch (message router). It's confusing indeed. The importance of this distinction is that the amqp1.0 driver in oslo.messaging is intended as a protocol based driver and not targetting any technology. That is to say, that it could be written using a library that is not qpid-proton and it can talk to any message router or message broker that has support for amqp 1.0. The ones we're targetting for the gate are rabbitmq (with the amqp 1.0 plugin enabled) and qpidd. Since we're at it, let me share some updates: The driver unittests now run on every python2 job and the work on python3 is almost done. There's also a functional tests gate like we have for other drivers. The missing bit is an integration gate, which we'll be start working on in the next couple of days. Hope the above helps clarifying confusions around this driver. That definitely clarifies the vision, thanks for sharing. There's also the question of _how_ to deprecate them. I figure we should deprecate when the driver is loaded. Is there an existing mechanism that someone can point me to, or should I look at adding that to oslo.messaging/stevedore? Normally we would recommend using versionutils from oslo.log, but we've been trying to avoid making oslo.log a dependency of the oslo libs because it uses some of them and that introduces cycles. Dims had a patch recently that just used a DeprecationWarning, and relied on oslo.log to redirect the warning to the log file. That seems like a good pattern to repeat. Can we use debtcollector to decorate the main driver class? A warning will be printted every time an instance of such class is created (rather than at import time). If we don't want to add a dependency on that, we could just use a DeprecationWarning as Doug mentioned. From a user perspective, as long as it only warns once per invocation of the consuming process (so it should warn when nova-conductor starts, not when
[openstack-dev] [app-catalog] App Catalog IRC meeting minutes - 6/18/2015
Thanks to all who joined the meeting this week. After the announcements we had a really good conversation and touched on a few important topics, and there's a lot more to discuss as we work through putting together our near-term roadmap. In addition to the topics noted in the log, we're already seeing progress on a Horizon panel that Kevin has been working on (nice work!) I'll also get a thread started here regarding using an object store for app catalog binary assets as well as a much broader thread regarding cross-project collaboration. Please join us on #openstack-app-catalog during the week, or next Thursday for our next weekly meeting! = #openstack-meeting-3: app-catalog = Meeting started by docaedo at 17:00:38 UTC. The full logs are available at http://eavesdrop.openstack.org/meetings/app_catalog/2015/app_catalog.2015-06-18-17.00.log.html . Meeting summary --- * LINK: https://wiki.openstack.org/wiki/Meetings/app-catalog (docaedo, 17:00:58) * rollcall (docaedo, 17:01:09) * Announcements (docaedo, 17:05:46) * LINK: https://review.openstack.org/187863 (docaedo, 17:05:54) * LINK: https://review.openstack.org/189993 (docaedo, 17:05:54) * LINK: https://review.openstack.org/187018 (docaedo, 17:05:54) * ACTION: docaedo start ML discussion re: object store for app catalog (docaedo, 17:06:37) * LINK: https://review.openstack.org/191990 (add site to cacti) (docaedo, 17:06:56) * LINK: https://review.openstack.org/190343 (enable IRC logging) (docaedo, 17:06:56) * LINK: https://review.openstack.org/191478 (mailing list) (docaedo, 17:06:57) * Proposal: stale entries (kfox) (docaedo, 17:09:24) * Versions for entries (docaedo) (docaedo, 17:29:26) * Discussion: ideas for getting more contributors involved? (docaedo, 17:33:37) * Discussion: other topics to cover, longer-term roadmap ideas (docaedo, 17:38:48) Meeting ended at 18:00:31 UTC. Action items, by person --- * docaedo * docaedo start ML discussion re: object store for app catalog People present (lines said) --- * docaedo (108) * kfox (69) * sgordon (52) * kztsv_mbp (16) * ativelkov (10) * muralia (10) * devkulkarni (9) * kebray (7) * datsun180b (3) * openstack (3) * fifieldt (2) * jlk (2) * arunrajan (1) * james_li (1) * jproulx (1) Generated by `MeetBot`_ 0.1.4 __ OpenStack Development Mailing 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][Ironic] Setting IPXE tag for dnsmasq
As I understand it, it just allows other rules to be written that specifically target pxe requests. So just enabling it won't have any effect. http://www.richud.com/wiki/Network_iPXE_dnsmasq_Examples_PXE_BOOT On Fri, Jun 19, 2015 at 9:21 AM, Miguel Angel Ajo mangel...@redhat.com wrote: What does iPXE do exactly?, What are the implications of having this enabled by default? Cheers, Miguel Ángel Kevin Benton wrote: I'd like to resurrect this thread. The patch has been sitting for quite a while. Since it doesn't modify the responses by default of DHCP messages, I'm inclined to just let it merge for now as a dnsmasq-specific change. Then maybe later we can figure out how to expose this via the dhcp opts API or a config value. If anyone has any concerns with that, please comment on the patch. Cheers, Kevin Benton On Mon, Apr 20, 2015 at 11:05 AM, Sean M. Collinss...@coreitpro.com wrote: Hi, In the following patch, I had a question about setting the IPXE tag by default. https://review.openstack.org/#/c/172040/ Basically, I'm unsure if we want to set this tag by default. I freely admit that I'm not an expert in PXE, but my thinking is that rather than enabling it by default, we should use the extra_dhcp_opts API extension to set the IPXE tag. http://specs.openstack.org/openstack/neutron-specs/specs/api/extra_dhcp_options__extra-dhcp-opt_.html Thoughts? -- Sean M. Collins __ OpenStack Development Mailing 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 -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] [all] To changes-since or not to changes-since
On 6/19/15, 14:39, Ian Cordasco ian.corda...@rackspace.com wrote: On 6/19/15, 14:26, Kevin L. Mitchell kevin.mitch...@rackspace.com wrote: On Fri, 2015-06-19 at 10:07 +0100, Chris Dent wrote: * Are there additional relevant pros and cons for the two proposals? * Are there additional proposals which can address the shortcomings in either? On the latter question, would using the If-Modified-Since header[1] make any sense as a possible solution? That at least would be a standard HTTP convention for this sort of thing, and tends to match up with the semantics of a changes-since query parameter. First, please use the updated RFC references (https://tools.ietf.org/html/rfc7232#section-3.3) If-Modified-Since does not. That's meant for entire resources. In other words, let's say you're listing images in Glance and you do GET /v2/images And your response has HTTP/1.1 200 OK Last-Modified: some_last_modified_value In the headers, when you do GET /v2/images If-Modified-Since: some_last_modified_value Then you should either get a: HTTP/1.1 204 No Content Or HTTP/1.1 200 OK Last-Modified: new_last_modified_value (all of the images you saw before) In other words, If-Modified-Since is meant purely for the state of the resource. It's main purpose is when used in conjunction with caching. That said, changes-since is more of a delta. If you need an analogy, think of it as an equivalent to $ git log 2015.1.0..stable/kilo It's just the deltas after a certain timestamp. Also, for what it's worth, I used to think If-Modified-Since was what you thought it was, but I found out how woefully wrong I was. It's not exactly intuitive, but you can toy with it via the GitHub API. Their /users and /repos resources will give you ETag and Last-Modified information. If you wait a little long enough for it to change and use either of those values to make a request, you'll get all of it again, from the beginning. 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] [api] [all] To changes-since or not to changes-since
On 06/19/2015 04:03 PM, Ian Cordasco wrote: On 6/19/15, 14:39, Ian Cordasco ian.corda...@rackspace.com wrote: On 6/19/15, 14:26, Kevin L. Mitchell kevin.mitch...@rackspace.com wrote: On Fri, 2015-06-19 at 10:07 +0100, Chris Dent wrote: * Are there additional relevant pros and cons for the two proposals? * Are there additional proposals which can address the shortcomings in either? On the latter question, would using the If-Modified-Since header[1] make any sense as a possible solution? That at least would be a standard HTTP convention for this sort of thing, and tends to match up with the semantics of a changes-since query parameter. First, please use the updated RFC references (https://tools.ietf.org/html/rfc7232#section-3.3) If-Modified-Since does not. That's meant for entire resources. In other words, let's say you're listing images in Glance and you do GET /v2/images And your response has HTTP/1.1 200 OK Last-Modified: some_last_modified_value In the headers, when you do GET /v2/images If-Modified-Since: some_last_modified_value Then you should either get a: HTTP/1.1 204 No Content Or HTTP/1.1 200 OK Last-Modified: new_last_modified_value (all of the images you saw before) In other words, If-Modified-Since is meant purely for the state of the resource. It's main purpose is when used in conjunction with caching. That said, changes-since is more of a delta. If you need an analogy, think of it as an equivalent to $ git log 2015.1.0..stable/kilo It's just the deltas after a certain timestamp. Also, for what it's worth, I used to think If-Modified-Since was what you thought it was, but I found out how woefully wrong I was. It's not exactly intuitive, but you can toy with it via the GitHub API. Their /users and /repos resources will give you ETag and Last-Modified information. If you wait a little long enough for it to change and use either of those values to make a request, you'll get all of it again, from the beginning. Right, it's the difference between the transport protocol semantics, and the application. Standard HTTP headers are about the transport protocol of HTTP, and do not care about your application. Here we're asking something about the application. -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] [all] [qpid] [zmq] [RabbitMQ] [oslo] Pending deprecation of driver(s).
On Fri, Jun 19, 2015 at 4:47 PM Clint Byrum cl...@fewbar.com wrote: Excerpts from Ken Giusti's message of 2015-06-19 08:01:46 -0700: On Fri, Jun 19, 2015 at 2:15 AM Flavio Percoco fla...@redhat.com wrote: On 18/06/15 16:37 -0400, Doug Hellmann wrote: Excerpts from Clint Byrum's message of 2015-06-18 12:47:21 -0700: Hello! I know there's been a lot of churn and misunderstanding over the recent devstack changes, so I wanted to make it clear where we're going with messaging drivers now that the policy [1] was approved. According to the policy, drivers need to have at least 60% unit test coverage, and an integration test suite with at least 3 popular OpenStack projects, with preference for Nova, Cinder, and Glance, and individuals who will support said test suite. So, with that, the following is the status of each driver in tree right now: rabbit - 89% Unit test coverage. Being the default in devstack, and the default in nearly every project's config files, this one is heavily integration tested. There are multiple individuals who have proven to be able to debug failures related to RabbitMQ and are well known in the community. +1 qpid - Unit test coverage is at 77%, so it passes that bar. I cannot find any integration testing being done, so it fails that. I also have not found anyone who will step up and support it. So this should be deprecated immediately. +1 - I believe Ken and the other folks interested in this indicated that the AMQP 1.0 driver should replace this one. The qpid driver should be deprecated, I'll be doing so in the next couple of days. Look forward to the patch. +1 Speaking of AMQP 1.0, you don't mention that one (it uses qpid, but is separate from the driver named qpid). I'd like to clarify something about the AMQP 1.0 driver. It's not a direct replacement for the qpidd one because it uses an entirely different protocol that recently became a standard. The reason I mention this is because it doesn't really require qpidd - not the double d - which is the broker daemon in the qpid family. I guess the confusion comes because the library it sits on top off is called qpid-proton. The qpid family is a set of tools that provide messaging capabilities. Among those you find qpidd (broker daemon), qpid-proton (amqp1.0 library), qpid-dispatch (message router). It's confusing indeed. The importance of this distinction is that the amqp1.0 driver in oslo.messaging is intended as a protocol based driver and not targetting any technology. That is to say, that it could be written using a library that is not qpid-proton and it can talk to any message router or message broker that has support for amqp 1.0. +1 - yeah, we really shouldn't be considering the amqp1 driver as simply the replacement qpid driver - as Flavio points out it has the potential to provide compatibility with other messaging back ends. Clint - can you also include separate metrics for the amqp1 driver? It's far less clear to me how to measure the unit test coverage of the amqp driver. I'll wait for Flavio's answer to my question about where the code lives, because it is definitely not organized like the others. No, it isn't. At the time we proposed this structure for the amqp1 driver, there really wasn't much formal structure within the driver directory. We had impl_rabbit, which was copied to impl_qpid in the hopes that all the rest of the code could be shared (it didn't work out very well). And the zmq code wasn't working at the time. And all of it was crammed into one flat directory. Rather than heap yet more stuff into that directory, we proposed to put the amqp1 driver into its own sub-directory. We chose a 'protocols' subdirectory, into which the amqp1 driver lives in the 'amqp' subdirectory. The hope was that other protocols would put their implementation bits into that protocols directory rather than lump them in directly under _drivers. It looks like the zmq driver will be structured a bit different from that - there will be a top level impl_zmq file along side a zmq_driver directory. I like the way zmq has laid out the sources, and maybe that should be the 'official' structure to olso.messaging drivers. If that's the case I'll be more that happy to arrange the amqp1 driver in a similar manner. I've gone off into the weeds, sorry. The amqp1 driver lives in _drivers/protocols/amqp directory (for now). And yes, those unit tests should be in the tests/drivers directory like everything else - when the tests/drivers directory was created that file wasn't moved. Oversight - I'll submit a patch to fix it. As far as coverage testing is concerned - I'm not sure how best to do this accurately. The amqp1 driver doesn't use any of the code in amqpdriver.py, amqp.py, common.py (I think),
[openstack-dev] [all][api] New API Guidelines ready for cross project review
Hi All, We have 3 API Guidelines that are ready for a final review. 1. Add section on filtering https://review.openstack.org/#/c/177468/ 2. http guideline expansion: background https://review.openstack.org/#/c/181931/ 3. Should not return server-side tracebacks https://review.openstack.org/#/c/183599/ If the API Working Group hasn’t received any further feedback, we’ll merge them on June 26. Thanks, Everett __ OpenStack Development Mailing 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] Specify a domain in mapping rules
You might need these changes, which are proposed but not merged:
https://review.openstack.org/#/q/status:open+project:openstack/keystone+branch:stable/kilo+topic:bug/1442787,n,z
Salut, Brant
On Thu, Jun 18, 2015 at 6:04 AM, J. Pablo Martín Cobos goi...@gmail.com
wrote:
Hi all,
I'm a Python/Django software developer [1]. We have to do an integration
of OpenStack and a Shibboleth IdP in my current project.
This is not a easy feature to configure... but finally we got it :-) Now
we only need specify a domain for the user different to the Federated
default domain. This domain depends on an attribute from the IdP.
Is it possible to get with stable/kilo branch? Is it a feature for the
next release? [2] These are my rules:
[
{
local: [
{
user: {
name: {0},
domain: {
name: {1}
}
}
},
{
group: {
id: 0ff59ec2f97646eb9350fe75478f9600
}
}
],
remote: [
{
type: identity
},
{
type: domain
}
]
}
]
I have tested with a lot of rules with little changes:
domain: {
name: Default
}
or
domain: {
id: default
}
or
domain: {
id: 14321243
}
etc... and this never works :-(
Could you help me?
REF's
1. https://github.com/goinnn
2.
https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3-os-federation-ext.rst
Thanks a lot!!,
--
Pablo Martín
Software engineer
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Implementation of ABC MetaClasses
On Fri, Jun 19, 2015 at 5:31 PM, Mike Perez thin...@gmail.com wrote: On Fri, Jun 19, 2015 at 3:43 PM, John Griffith john.griffi...@gmail.com wrote: Anyway, maybe I'm missing a big advantage here, but without understanding what this gains it makes the code structure a bit hard to maintain and follow in a number of ways. For example, in order to implement this in the existing drivers they need to be changed to have an inheritance structure like this: [5]. As opposed to just using the decorator which everything would automatically propagate to any sub-class and enforce implementation with no change or maintenance to existing drivers; but it still enforces implementation of the required methods. I'd love if folks could study some of this a bit and let me know what it is that I'm missing here. Is there some value that I'm unaware of that the muti-inheritance paradigm in the drivers provides us? I remember from the Kilo midcycle meetup [1] that you were part of, we discussed this accomplishing a few things: Sure, I was there, I even proposed the use of abc as a great idea. I didn't catch the part about the optional classes and what that would look like however. * The BaseVD represents the functionality we require from all drivers. Yep * The additional ABC classes represent features that are not required yet. * These are represented by classes because some features require a bundle of methods for it to be fulfilled. Consistency group is an example. [2] Sure, I suppose that's fine for things like CG and Replication. Although I would think that if somebody implemented something optional like CG's that they should be able to figure out they need all of the cg methods, it's kinda like that warning on ladders to not stand on the very top rung. By the way, maybe we should discuss the state of optional API methods at the mid-cycle. * Any driver that wishes to mark their driver as supporting a non-required feature inherits this feature and fulfills the required methods. Yeah... ok, I guess. * After communication is done on said feature being required, there would be time for driver maintainers to begin supporting it. * Eventually that feature would disappear from it's own class and be put in the BaseVD. Anybody not supporting it would have a broken driver, a broken CI, and eventually removed from the release. Sure, I guess my question is what's the real value in this intermediate step. The bulk of these are things that I'd argue shouldn't be optional anyway (snapshots, transfers, manage, extend, retype and even migrate). Snapshots in particular I find surprising to be considered as optional. * Some people had thoughts of having a way generate a matrix with this information, which I dislike the idea of. Yeah, back to the dreaded Matrix, I can't imagine anything worse for Cinder than a matrix of supported API calls on a driver per driver basis. Why have the middle step of having the non-required features be represented in some abc class? I guess it's a form of reference and failing sooner for not fulfilling the methods with the correct signature. This doesn't check if those methods return the right information though. So maybe it's not worth it. I'm not sure that works anyway, I mean... I can still implement whatever methods in my driver I want, if I don't inherit from the VD class it doesn't matter, it's not checked anywhere otherwise. Marc provided a patch that would show RBD switching to this model. This revealed my main objection to the change which was the ugliness of having to inherit from all these classes, however, no one else really cared. Hmm... I wish I would've caught this at the time, because I most CERTAINLY would have agreed with you 100% as you can probably tell by my thoughts on the subject in reviews, IRC and this ML post. [1] - https://etherpad.openstack.org/p/cinder-meetup-winter-2015 [2] - https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py#L902 -- 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 __ OpenStack Development Mailing 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] [Security] Nominating Michael McCune for Security CoreSec
On 2015-06-15 16:16:57 - (-), Travis McPeak wrote: I'd like to propose Michael McCune for CoreSec membership. [...] I'm in favor--Michael has been very helpful so far. Thanks! -- Jeremy Stanley signature.asc Description: Digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] [all] Proposal for Glance Artifacts Sub-Team meeting.
Voting is now closed as we did not hear any concerns and there were positive votes on the review. So, we would like to reserve a spot for the meeting time date (for the appropriate duration) as per the latest on https://review.openstack.org/#/c/192270/ . Seems like gerrit is best way to detect conflicts and any racy proposals so, I would like to request people with appropriate permissions to merge the proposal. Thanks. On 6/16/15 12:02 PM, Nikhil Komawar wrote: Hi all, We have planned a fast track development for Glance Artifacts; also it would be our v3 API. To balance pace, knowledge sharing, synchronous discussion on ideas and opinions as well as seeing this great feature through in Liberty: We hereby propose a non-mandatory, open to all, sub-team meeting for Glance Artifacts. Please vote on the time and date: https://review.openstack.org/#/c/192270/ (Note: Run the tests for your vote to ensure we are considering feasible non-conflicting times.) We will start the meeting next week unless there are strong conflicts. -- Thanks, Nikhil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic][Horizon][Tuskar-ui] Making a dashboard for Ironic
Hi Jim, Your characterization of this is incomplete. These are not two equal projects proposing the same thing in different ways, and while I very much want to encourage collaboration, I value our community and feel that this was not done in the spirit of that community. To be clear: ironic-webclient has been developed with the knowledge and support of the Ironic developer community, and was not moved into the openstack/ namespace on my request, because I have been holding projects to a certain level of maturity before including them in Ironic, roughly equivalent to the TC's bar for big tent inclusion. On the other hand, ironic-dashboard was done without the knowledge of any Ironic cores, nor with even a heads up to the Ironic or Horizon PTLs. Rather than an open design process, this code was just dropped on github and Infra was asked to approve the project creation. I have not had the opportunity to talk with its author *at all* yet. I'm glad that ya'll didn't just approve the project creation request without checking with me, and I'm glad we are now having this discussion. Now that that is cleared up, let's move on. Hi Zhenguo, I have some questions about ironic-dashboard that I need answered before the Ironic Project Team accepts responsibility for it. The git history appears to be squashed [1], and most files don't have an attribution header [2], and none of the headers refer to the company who appears to be behind this (Huawei). What's the rationale for these inconsistencies, and who is actually behind the code? Are you going to maintain this project personally, or is there a team at Huawei (or somewhere else) that is going to do that? Or are you expecting Ironic's current developer teams to take ownership of this code and maintain it? Are you/they going to become part of Ironic's community, attend our weekly meetings, and follow our design process? What is the vision / goal that is being working towards? What is the scope of this dashboard? How does it fit in with our existing plans? I'm not entirely opposed to having two separate UI projects for Ironic at the moment, but we should be very clear about the rationale if we go that route. -Devananda [1] https://github.com/niuzhenguo/ironic-dashboard/commit/4be73d19e54eb75aa31da3d1a38fa65c1287bc7b [2] https://github.com/niuzhenguo/ironic-dashboard/search?q=copyright On Fri, Jun 19, 2015 at 12:00 PM James E. Blair cor...@inaugust.com wrote: Hi all, I'm glad that by asking the ironic-dashboard creators to propose their project to ironic initially (rather than stackforge) we have prompted this conversation. We now know that two independent groups of people have created standalone ironic dashboards, neither of which is currently part of an OpenStack project. We have an opportunity for those teams to begin collaborating now. I would encourage them to do so, along with both the Ironic and Horizon teams, on a path forward. Let's end the talk of -1ing someone's every patch and instead avail ourselves of one of the many ways in our community we can achieve and record consensus. Michael, you have a plan with a number of steps, one of which is already an approved cross-project spec. Perhaps that is a good starting point for this discussion. -Jim __ OpenStack Development Mailing 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] Angular dependencies and the hz.dashboard namespace
Heres a summary of what we talked about:1.Need to retain the same file structure so that pluggins continue to work.Example:https://github.com/stackforge/monasca-ui/tree/master/monitoringBasically we have existing pluggins that use this file structure, we need to honor it.This is not directly related to what we are talking about, but it does mean that we need to move static files out of/openstack_dashboard/static/MYDASHBOARD/* and into/openstack_dashboard/dashboards/MYDASHBOARD/static/*2.Auto-discovery of static resources will need to also honor the pluggin model above, hence the file structure above.You will still need to manually define the ADD_ANGULAR_MODULES in your enabled file, auto-discovery doesn't know what you want enabled.Sean's patch is going to do that, but having some issues with SCSS.https://review.openstack.org/#/c/191592/3.hz.dashboard module will be empty because the hz.dashboard.MYDASHBOARD module will live at the app level viaADD_ANGULAR_MODULES. I would argue that it makes no sense to have an empty module, my preference is to just delete it.Constants are globally available in the app, something I think actually should be avoided, not encouraged.4.Having hz.dashboard.tech-debt and workflow in the enabled file is not correct.They are core components needed by all dashboards and should be loaded by default, not via the pluggin mechanism.https://review.openstack.org/#/c/193401/4/openstack_dashboard/enabled/_10_project.pyLets say I have my own dashboard call MYDASHBOARD, and I decided to disable all other dashboards except mine,all of a sudden, things will break horribly because tech-debt and workflow are not loaded. I would have to either:a. load the _10_project enabled fileb. copy/paste over the dependencies from _10_projectFurthermore, if I have hz.dashboard module, where do I load that, in _10_project or _x_MYDASHBOARD?Same issue when I disable entire dashboards.Tyr's patch will address this problem by having a core module.https://review.openstack.org/#/c/193681/-Richard Jones r1chardj0...@gmail.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Richard Jones r1chardj0...@gmail.comDate: 06/19/2015 03:49PMSubject: [openstack-dev] Angular dependencies and the hz.dashboard namespaceThe "Adding Angular Identity Dashboard"[1] patch exposed an issue I saw previously that worried me[2].I believe during recent Horizon work the concept of angular module namespaces and dependencies have been conflated. There's this idea that if you create a submodule inside a module namespace you *must* have that module depend on that submodule. I believe that is incorrect - just look at the angular codebase itself, and how it is used. If you want the ngCookies module in a couple of places then you have those modules depend on ngCookies (or, more likely, you just add it as a dependency to the app). The point is it's not just added automatically to the "ng" module as a dependency. If you need to use a module's functionality, you depend on the module. You don't just have all your modules *automatically* pulled in as dependencies. I have proposed a patch to remedy this for the existing "optional"[3] project dashboard[4].I believe it is unnecessary to add extension of the hz.dashboard dependency list[5] since we already have an extensible dependency list for the application itself (which the hz.dashboard dependency list just extends).To answer the question explicitly raised "what is the point of having the hz.dashboard module if it has no dependencies?" It does two things: it defines the namespace in a formal manner (by itself unnecessary, but it's still nice to do) and it defines a constant which is used by other code. Eventually it may define more. There is an important difference between Python modules and Angular modules here - using a Python module like hz.dashboard in this way could cause problems because of the way Python sub-module namespaces and import ordering work. Angular's modules work very differently, and are not burdened by the same issues. In Python that constant would most likely have to be pushed out to a sub-module to avoid import loops. Richard[1]https://review.openstack.org/190852[2]https://bugs.launchpad.net/horizon/+bug/1466713[3] There may be other issues that prevent the project dashboard being optional - there are dependencies in Python-land from the admin dashboard hard-coded over to the project dashboard, for example. It might be a good idea to remedy that, since I think it probably exposes some other structural issues in the plugin mechanism we're providing to deployers.[4]https://review.openstack.org/#/c/193401/[5]https://review.openstack.org/193671 __OpenStack Development Mailing List (not for usage questions)Unsubscribe:
Re: [openstack-dev] [Cinder] Implementation of ABC MetaClasses
On Fri, Jun 19, 2015 at 3:43 PM, John Griffith john.griffi...@gmail.com wrote: Anyway, maybe I'm missing a big advantage here, but without understanding what this gains it makes the code structure a bit hard to maintain and follow in a number of ways. For example, in order to implement this in the existing drivers they need to be changed to have an inheritance structure like this: [5]. As opposed to just using the decorator which everything would automatically propagate to any sub-class and enforce implementation with no change or maintenance to existing drivers; but it still enforces implementation of the required methods. I'd love if folks could study some of this a bit and let me know what it is that I'm missing here. Is there some value that I'm unaware of that the muti-inheritance paradigm in the drivers provides us? I remember from the Kilo midcycle meetup [1] that you were part of, we discussed this accomplishing a few things: * The BaseVD represents the functionality we require from all drivers. * The additional ABC classes represent features that are not required yet. * These are represented by classes because some features require a bundle of methods for it to be fulfilled. Consistency group is an example. [2] * Any driver that wishes to mark their driver as supporting a non-required feature inherits this feature and fulfills the required methods. * After communication is done on said feature being required, there would be time for driver maintainers to begin supporting it. * Eventually that feature would disappear from it's own class and be put in the BaseVD. Anybody not supporting it would have a broken driver, a broken CI, and eventually removed from the release. * Some people had thoughts of having a way generate a matrix with this information, which I dislike the idea of. Why have the middle step of having the non-required features be represented in some abc class? I guess it's a form of reference and failing sooner for not fulfilling the methods with the correct signature. This doesn't check if those methods return the right information though. So maybe it's not worth it. Marc provided a patch that would show RBD switching to this model. This revealed my main objection to the change which was the ugliness of having to inherit from all these classes, however, no one else really cared. [1] - https://etherpad.openstack.org/p/cinder-meetup-winter-2015 [2] - https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py#L902 -- 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] [api] [all] To changes-since or not to changes-since
On 06/19/2015 05:07 AM, Chris Dent wrote: There's an open question in the API-WG on whether to formalize or otherwise enshrine the concept of a changes-since query parameter on collection oriented resources across the projects. The original source of this concept is from Nova's API: http://docs.openstack.org/developer/nova/v2/polling_changes-since_parameter.html There are arguments for and against but we've been unable to reach a consensus so the agreed next step was to bring the issue to the mailing list so more people can hash it out and provide their input. The hope is that concerns or constraints that those in the group are not aware of will be revealed and a better decision will be reached. The basic idea of changes-since is that it can be used as a way to signal that the requestor is doing some polling and would like to ask Give me stuff that has changed since the last time I checked. As I understand it, for the current implementations (in Nova and Glance) this means including stuff that has been deleted. Repeated requests to the resource with a changes-since parameter gives a running report on the evolving state of the resource. This is intended to allow efficient polling[0]. The pro camp on this likes it because this is very useful and quite humane: The requestor doesn't need to know the details of how the query is is implemented under the hood. That is, if there are several timestamps associated with the singular resources in the collection which of those are used for time comparison and which attributes (such as state with a value of deleted) are used to determine if a singular resource is included. The service gets to decide these things and in order for efficient polling to actually be achieved it needs to do in order to make effective queries of the data store. The con camp doesn't like it because it introduces magic, ambiguity and inconsistency into the API (when viewed from a cross-project perspective) and one of the defining goals of the working group is to slowly guide things to some measure of consistency. The alternate approach is to formulate a fairly rigorous query system for both filtering[1] and sorting[2] and use that to specify explicit queries that state I want resources that are newer than time X in timestamp attribute 'updated_at' _and_ have attribute 'state' that is one of 'foo', 'bar' or 'baz'. (I hope I have represented the two camps properly here and not introduced any bias. Myself I'm completely on the fence. If you think I've misrepresented the state of things please post a clarifying response.) The questions come down to: * Are there additional relevant pros and cons for the two proposals? * Are there additional proposals which can address the shortcomings in either? Thanks for your input. [0] Please try to refrain from responses on the line of ha! efficiency! that's hilarious! and ZOMG, polling, that's so last century. Everybody knows this already and it's not germane to the immediate concerns. We'll get to a fully message driven architecture next week. This week we're still working with what we've got. [1] filtering guideline proposal https://review.openstack.org/#/c/177468/ [2] sorting guideline proposal https://review.openstack.org/#/c/145579/ I think that is a reasonable summation. My personal feeling is that if 'changes-since' is strictly defined as the AND of 2 other standard filters, it's not feeling very relevant to recommend it existing. It's now just a 2nd way to do exactly the same thing, and all we can do is screw it up (A man with one watch always knows what time it is. A man with two watches is never quite sure.). If it's left a little more vague of for resources that you expect to be regularly polled, this can provide an interface to only show the consumer relevent resources. If you choose to implement this, you must document what criteria is used to return resources from the url. And allow the possibility that their might be different sensible definitions depending on the resource, I'm happier about it. -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] [all] [qpid] [zmq] [RabbitMQ] [oslo] Pending deprecation of driver(s).
Clint Byrum wrote: Excerpts from Flavio Percoco's message of 2015-06-18 23:14:49 -0700: On 18/06/15 16:37 -0400, Doug Hellmann wrote: Excerpts from Clint Byrum's message of 2015-06-18 12:47:21 -0700: Hello! I know there's been a lot of churn and misunderstanding over the recent devstack changes, so I wanted to make it clear where we're going with messaging drivers now that the policy [1] was approved. According to the policy, drivers need to have at least 60% unit test coverage, and an integration test suite with at least 3 popular OpenStack projects, with preference for Nova, Cinder, and Glance, and individuals who will support said test suite. So, with that, the following is the status of each driver in tree right now: rabbit - 89% Unit test coverage. Being the default in devstack, and the default in nearly every project's config files, this one is heavily integration tested. There are multiple individuals who have proven to be able to debug failures related to RabbitMQ and are well known in the community. +1 qpid - Unit test coverage is at 77%, so it passes that bar. I cannot find any integration testing being done, so it fails that. I also have not found anyone who will step up and support it. So this should be deprecated immediately. +1 - I believe Ken and the other folks interested in this indicated that the AMQP 1.0 driver should replace this one. The qpid driver should be deprecated, I'll be doing so in the next couple of days. Look forward to the patch. Speaking of AMQP 1.0, you don't mention that one (it uses qpid, but is separate from the driver named qpid). I'd like to clarify something about the AMQP 1.0 driver. It's not a direct replacement for the qpidd one because it uses an entirely different protocol that recently became a standard. Could you clarify where the code actually is, or more specifically, why the code doesn't follow the same organization as the others? There's no impl_amqp and the tests don't live in tests/drivers, but in tests/test_amqp_driver. I left it out because I didn't realize this new driver lived in tree. Anyway, this driver appears to land in the prospective drivers category in the spec. We failed to call out drivers that are still considered experimental, however I kind of feel like the driver should be out of tree until such time as it is usable enough that it _could_ have an integration test. So, is it feasible that this driver will fall in-line with the others in the next 6 months, or should we be looking at either revising the policy, or moving it out of tree until it is capable of that? The reason I mention this is because it doesn't really require qpidd - not the double d - which is the broker daemon in the qpid family. I guess the confusion comes because the library it sits on top off is called qpid-proton. The qpid family is a set of tools that provide messaging capabilities. Among those you find qpidd (broker daemon), qpid-proton (amqp1.0 library), qpid-dispatch (message router). It's confusing indeed. The importance of this distinction is that the amqp1.0 driver in oslo.messaging is intended as a protocol based driver and not targetting any technology. That is to say, that it could be written using a library that is not qpid-proton and it can talk to any message router or message broker that has support for amqp 1.0. The ones we're targetting for the gate are rabbitmq (with the amqp 1.0 plugin enabled) and qpidd. Since we're at it, let me share some updates: The driver unittests now run on every python2 job and the work on python3 is almost done. There's also a functional tests gate like we have for other drivers. The missing bit is an integration gate, which we'll be start working on in the next couple of days. Hope the above helps clarifying confusions around this driver. That definitely clarifies the vision, thanks for sharing. There's also the question of _how_ to deprecate them. I figure we should deprecate when the driver is loaded. Is there an existing mechanism that someone can point me to, or should I look at adding that to oslo.messaging/stevedore? Normally we would recommend using versionutils from oslo.log, but we've been trying to avoid making oslo.log a dependency of the oslo libs because it uses some of them and that introduces cycles. Dims had a patch recently that just used a DeprecationWarning, and relied on oslo.log to redirect the warning to the log file. That seems like a good pattern to repeat. Can we use debtcollector to decorate the main driver class? A warning will be printted every time an instance of such class is created (rather than at import time). If we don't want to add a dependency on that, we could just use a DeprecationWarning as Doug mentioned. From a user perspective, as long as it only warns once per invocation of the consuming process (so it should warn when nova-conductor starts, not when nova-conductor sends a message), then I think we should just use DeprecationWarning's
[openstack-dev] [Cinder] Implementation of ABC MetaClasses
Hey Everyone, So I've talked a little in bits and pieces regarding the implementations that are going in for the ABC metaclass work. First off, I think the use of ABC is a good idea and has value, particularly as we approach/surpass 50 third party drivers. The only thing that I'm wondering if we could do better is the metaclass tagging of things. We have ended up with something that IMO is rather confusing and I'm not sure what the value is (perhaps this is simply a misunderstanding on my part and somebody can enlighten me). What I'm referring to is the all of the *VD classes we've created, and the fact that each driver now has an inheritance structure of multiple classes. So for example, we have a VD class for what used to be class Driver here: [1] It seems we could've just left this as Driver and added the abc decorators to abstract methods in the base object. Instead though we have something I don't quite understand: we have abc decorators on the methods AND we have these special meta-classes for a number of the methods. For example: [2] and [3]. What's the value here, I'm unclear on what the goal is. There is an alternative that just uses the abc decorator, and no special class designations. If you attach the abc decorator to any method in a base class, it indicates that any inheriting driver MUST implement that method. If said sub-class does NOT implement that method, the load of the module will fail. This really requires no additional code or maintenance other than just adding the decorator to the mandatory methods in the base class. There examples of what I'm describing in the target drivers [4]. Anyway, maybe I'm missing a big advantage here, but without understanding what this gains it makes the code structure a bit hard to maintain and follow in a number of ways. For example, in order to implement this in the existing drivers they need to be changed to have an inheritance structure like this: [5]. As opposed to just using the decorator which everything would automatically propagate to any sub-class and enforce implementation with no change or maintenance to existing drivers; but it still enforces implementation of the required methods. I'd love if folks could study some of this a bit and let me know what it is that I'm missing here. Is there some value that I'm unaware of that the muti-inheritance paradigm in the drivers provides us? Thanks, John [1]: https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py#L247 [2]: https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py#L871 [3]: https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py#L925 [4]: https://github.com/openstack/cinder/blob/master/cinder/volume/targets/driver.py#L42 [5]: https://github.com/openstack/cinder/commit/a8030b7cb6f8199234d85d8c7574b563e5a24fe9#diff-0e51a408cd93c9e5bf454edeee2fe5c0 __ OpenStack Development Mailing 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][nova][ironic] Microversion API HTTP header
In line (at the bottom) From: Devananda van der Veen [mailto:devananda@gmail.com] Sent: Friday, June 19, 2015 12:40 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [api][nova][ironic] Microversion API HTTP header On Wed, Jun 17, 2015 at 7:31 AM Jay Pipes jaypi...@gmail.commailto:jaypi...@gmail.com wrote: On 06/17/2015 06:30 AM, Lucas Alvares Gomes wrote: overlap there rather than competition), how crazy does it sound if we say that for OpenStack Nova is the compute API and Ironic the Bare Metal API and so on? Would that be an unacceptable power grab? It's not that it's unacceptable, but I think that things weren't projected that way. Jay started this thread with this sentence: To be blunt, Nova is the *implementation* of the OpenStack Compute API. Ironic is the *implementation* of the OpenStack BareMetal API. Which I don't think is totally correct, at least for Ironic. The Ironic's API have evolved and shaped as we implemented Ironic, I think that some decisions we made in the API makes it clear, e.g: * Resources have JSON attributes. If you look at some attributes of the resources you will see that they are just a JSON blob. That's by design because we didn't know exactly how the API should look like and so by having these JSON fields it allows us to easily extend the resource without changing it's structure [1] (see driver_info, instance_info, extra) OK. Nothing wrong with that. * We have a vendor endpoint. This endpoint allows vendor to extend our API to expose new hardware capabilities that aren't present in the core API. Once multiple vendors starts implementing the same feature on this endpoint we then decide whether to promote it to the core API. This is a problem. The above means that there is no single OpenStack BareMetal API. This means developers that want to write against an OpenStack BareMetal API cannot rely on different deployments of Ironic exposing the same API. That is a recipe for a lack of interoperability and decreased developer ease of use. Nope - not a problem. Actually it's been really helpful. We've found this to be a better way to implement driver extensions -- it's clearly *not* part of Ironic's API, and it's communicated as such in the API itself. Any standard part of Ironic's functionality is exposed in the standard API, and hardware-specific extensions, which are not supported by enough vendors to be standardized yet, are only exposed through the vendor-specific API endpoint. It's very clear in the REST API what this is -- the end points are, for example, GET /v1/nodes//vendor_passthru/methods POST /v1/nodes//vendor_passthru?method=fooparam=bar GET /v1/drivers//methods ... and so on. This provides a mechanism to discover what resources and methods said hardware vendor exposes in their hardware driver. We have always supported out of tree drivers, and it is possible to upgrade Ironic without upgrading the driver (or vice versa). Also to note, our client library doesn't support any of the vendor-specific methods, and never will. It only supports Ironic's API's ability to *discover* what vendor-specific methods that driver exposes, and then to transparently call to them. And none of that is relevant to other OpenStack projects. So if an operator wants to write a custom app that uses foo-vendor's advanced-foo-making capabilities because they only buy Foo hardware -- that's great. They can do that. Presumably, they have a support contract with Foo vendor. Ironic is merely providing the transport between them. * There's a reservation attribute in the Node's resource [1] which valueis the hostname of the conductor that is currently holding an exclusive lock to act upon this node. This is because internally we use a distributed hashing algorithm to be able to route the requests from the API service to a conductor service that is able to manage that Node. And having this field in the API That is just leaking implementation inappropriately out of the public REST API, and shouldn't be encouraged, IMHO. Nova has a number of these leaky parts of its API, too, of course. Just look at the os-guests API extension, which only works when you're using Xen under the hood, thereby leaking implementation details about the underlying infrastructure out through the public REST API. yes, this is leaky in the purest sense, but remember that ironic doesn't expose a *public* API. Only operators and other services should be talking directly to it -- and this field was requested by operators who find it helpful to know which service has locked a resource. I don't think that any of those decisions were bad by the way, this have helped us a lot to understand how a service to manage Bare Metal machines should looks like, and we have made wrong decisions too (You can get the same information by GET'ing different endpoints in the API, the Chassis resources currently have
Re: [openstack-dev] [oslo.messaging][zeromq] Next step
Do we have a good understanding of what is expected of zmq wrt rabbitMQ? Like in what part of the bell curve or use cases would you see it? Or indirectly, where do we see RabbitMQ lacking today that maybe ZMQ could handle better? I have tried to find any information on very large scale deployment of OpenStack and could not get a firm number (in terms of number of compute nodes). Does the OpenStack foundation keeps track of this information somewhere? Alec On 6/19/15, 12:56 AM, Thierry Carrez thie...@openstack.org wrote: Flavio Percoco wrote: There's a 95% of deployments using rabbit not because rabbit is the best solution for all OpenStack problems but because it was the one that works best now. The lack of support on other drivers caused this and as long this lack of support on such drivers persist, it won't change. There is 95% of deployments using rabbit because RabbitMQ serves the middle of the Bell curve of the use cases perfectly well. For OpenStack to be ubiquitous, we need to extend beyond our comfort zone of use cases and support technology that will let us address those. I see zmq has an enabler for that: it will solve other classes of problems triggered by extreme use cases. So yes, obviously RabbitMQ dominance should (and will naturally) drive the development and maintenance efforts. But we should at least try to not make the lives of those who explore new trails (and reach to new use cases) miserable. -- 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] [Cinder] Implementation of ABC MetaClasses
Funny you should mention needing all of the CG methods... A VD group (ConsistencyGroupVD) was added to contain the 4 CG methods from Juno. Then more CG methods were added to VolumeDriver in Kilo, but they weren’t added to ConsistencyGroupVD. But you *can’t* add them to ConsistencyGroupVD until every driver that advertises ConsistencyGroupVD has implemented them, lest ConsistencyGroupVD imply something false. You could add them to ‘ConsistencyGroupVD_v2’, but that’s ugly. This whole VD thing seems just a little too neat, since it doesn’t lend itself to evolution of features over time. I’ve wondered if a little runtime introspection wouldn’t be a cleaner solution. -- Clinton Knight From: John Griffith john.griffi...@gmail.commailto:john.griffi...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Friday, June 19, 2015 at 7:59 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Cinder] Implementation of ABC MetaClasses Sure, I suppose that's fine for things like CG and Replication. Although I would think that if somebody implemented something optional like CG's that they should be able to figure out they need all of the cg methods __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.messaging][zeromq] Next step
Excerpts from Alec Hothan (ahothan)'s message of 2015-06-19 17:18:41 -0700: Do we have a good understanding of what is expected of zmq wrt rabbitMQ? Like in what part of the bell curve or use cases would you see it? Or indirectly, where do we see RabbitMQ lacking today that maybe ZMQ could handle better? I have tried to find any information on very large scale deployment of OpenStack and could not get a firm number (in terms of number of compute nodes). Does the OpenStack foundation keeps track of this information somewhere? The current scale-out story is cells. I don't have the exact numbers on nodes per cell, but it's low enough that some larger scale clouds don't like the economics. Cells requires a duplication of control-plane infrastructure that makes scaling out possible, but overly expensive. It's fine if you are stuck and don't have time to help develop another solution, but if we take a long look at the way we use RabbitMQ for RPC, it's possible we'd realize that RabbitMQ is not great for two-way synchronous comms, and in fact, there's zero reason to ask it to do that well. Using 0mq for that alone would probably lighten the load enough to expand the scale for medium-scale users not to have to use cells. Then if we do fanouts and casts via 0mq doing direct messages, or a scale-out broker like Kafka or Gearman, then we suddenly have each box doing just a small part of the control plane scaling, and less spofs. All of this is not really oslo.messaging work, but architecture work. I know Robert Collins has been asking for people to take a look at these types of issues, and I agree with him that they need to be addressed directly rather than piecemeal. But we have to pay mind to the fact that what we have now does work for many many users. This is why having pluggable driver interfaces so experiments can happen at each level is an important thing to continue supporting. What's not necessarily important is keeping all the drivers people have tried in tree. __ OpenStack Development Mailing 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] Debian already using Python 3.5: please gate on that
On 19 June 2015 at 02:18, Ian Cordasco ian.corda...@rackspace.com wrote: On 6/18/15, 08:44, Thomas Goirand z...@debian.org wrote: Does this mean that Debian is going to ignore classifiers for all projects that list 3.4 without listing 3.5 and will start reporting bugs against them before upstream projects have time to start testing against 3.5? Why is Debian running tests against versions of python that upstream doesn't claim to support? I think this is taking a rather extreme interpretation of Thomas' email. Here's what I read: - Debian 9.0 is hoping to be 3.5 not 3.4 - The experimental staging area in Debian has 3.5 already and is starting to find out what packages are going to have issues - Some of OpenStack does. - Please introduce 3.5 as a supported Python as soon as we can. Which is I think a reasonable request. Whether we want to support 3.4 and 3.5, or just 3.4 and then just 3.5 is an ecosystem question IMO, not an upstream one. 3.4 and 3.5 are very similar when you consider the feature set crossover with 2.7. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG
Almost all of our discussions so far on this topic have left something out, which Monty pointed out to me last week. I'm following up now because E_TRAVEL... tldr; What we're versioning here are API's, not packages. It's not a question of numbering and dependency ordering, but of communicating support[ed|able] interfaces between running services. Libtool is more relevant than semver. http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html Right now we lack a means to express that the API response is compatible-with a particular previously-released version of the API. If we had that, instead of current-version, I believe we would have much happier users (and a happier Dmitry and jroll). Long version... Every HTTP response from Ironic today includes three headers: min, max, and version. The service can present an older API version, as long as it is greater-than-or-equal-to the minimum supported version, even if that version is incompatible with the maximum supported version. It does this by rewriting responses to match what was expected in the requested (older) version. When the newer version is identical *for all interfaces present* in the older version, this can be called compatible. Dmitry's point is that we don't need to hide newer interfaces from users who request an older API version, because the client won't know or care about things that weren't in the version it requested. However, we *do* need to signal their presence, and we don't have a good means for that right now. We also need to signal to the client that the response given is compatible with a certain age of API, even if it's not exactly the same. And we don't have any means for that, either. Time for an example Let's say that an incompatible change was made in v1.3. Let's also say that a change was made in v1.5 that added a new endpoint. Today, this is what the response headers would look like when calling a server running v1.5. a) client requests v1.2, receives headers (min: 1.1, max: 1.5, current: 1.2) b) client requests v1.4, receives headers (min: 1.1, max: 1.5, current 1.4) c) client requests v1.5, receives headers (min: 1.1, max: 1.5, current: 1.5) What we have implemented today is that in case (b), the service will *hide* any changes that we introduced in v1.5. But those changes did not affect any functionality of the v1.4 API, so Dmitry objects to this. So do I. The issue at hand is the response in case (b) ... though after spending the last several months working on api versioning, I actually think all of those are poor responses. What I believe we should have: a) client requests v1.2, receives headers (min: 1.1, max: 1.5, compatible-with: 1.1) b) client requests v1.4, receives headers (min: 1.1, max: 1.5, compatible-with: 1.3) b) client requests v1.5, receives headers (min: 1.1, max: 1.5, compatible-with: 1.3) Yes -- (b) and (c) are identical responses. Discuss. -Devananda On Tue, Jun 16, 2015 at 7:13 AM Dmitry Tantsur dtant...@redhat.com wrote: On 06/16/2015 03:47 PM, Jim Rollenhagen wrote: On Tue, Jun 16, 2015 at 08:56:37AM +0200, Dmitry Tantsur wrote: On 06/04/2015 08:58 AM, Xu, Hejie wrote: Hi, guys, I’m working on adding Microversion into the API-WG’s guideline which make sure we have consistent Microversion behavior in the API for user. The Nova and Ironic already have Microversion implementation, and as I know Magnum _https://review.openstack.org/#/c/184975/_ is going to implement Microversion also. Hope all the projects which support( or plan to) Microversion can join the review of guideline. The Mircoversion specification(this almost copy from nova-specs): _https://review.openstack.org/#/c/187112_ And another guideline for when we should bump Mircoversion _https://review.openstack.org/#/c/187896/_ As I know, there already have a little different between Nova and Ironic’s implementation. Ironic return min/max version when the requested version doesn’t support in server by http-headers. There isn’t such thing in nova. But that is something for version negotiation we need for nova also. Sean have pointed out we should use response body instead of http headers, the body can includes error message. Really hope ironic team can take a look at if you guys have compelling reason for using http headers. And if we think return body instead of http headers, we probably need think about back-compatible also. Because Microversion itself isn’t versioned. So I think we should keep those header for a while, does make sense? Hope we have good guideline for Microversion, because we only can change Mircoversion itself by back-compatible way. Thanks Alex Xu Hi all! I'd like to try put in feedback based on living with microversions in Kilo release of Ironic. And here's my take, based on my experiences. Keep in mind I'm a core reviewer, a developer, and an operator of Ironic. Thanks Jim, much appreciated!
Re: [openstack-dev] [cross-project] RBAC Policy Basics
On 06/19/2015 01:08 AM, Osanai, Hisashi wrote: Adam, Thank you for the information RBAC Policy Basics. Thursday, June 18, 2015 1:47 AM, Adam Young wrote: However, we have found a need to have a global override. This is a way a cloud admin that can go into any API anywhere and fix things. This means that Glance, Neutron, Nova, and Keystone should be able to share a policy file. What situations does a shared policy file require? For example, there are policy files for Nova and Cinder and they have same targets such as context_is_admin, admin_or_owner and default. A lot of these internal rules most likely should be removed. They do conflict, with differenet interpretations between the proejcts. They are also confusing two different things: scope and role./ I think we should make it a point to keep them separate. (1) load both policy.json files on a server process then the targets will be overridden by 2nd loaded policy.json. A cloud admin changes the 2nd policy.json only. Actually, we should specify when uploading whether it is an override or not. If it is not an over rider, we would only pick up these new rules that are not covered by existing ones. I suspect that managing the stack of policy files this wayi s going to be much like a git repo. (2) A cloud admin changes the targets in different policy.json files at one time. Did you mention about case(2)? Nova: https://github.com/openstack/nova/blob/master/etc/nova/policy.json Cinder: https://github.com/openstack/cinder/blob/master/etc/cinder/policy.json context_is_admin: role:admin, admin_or_owner: is_admin:True or project_id:%(project_id)s, default: rule:admin_or_owner, I think we will need service specific defaults, although I could see the case for the default everywhere being if not specified, match the project, and require the admin role. But matching the project is going too be tricky. Nova has it in teh URL for the resources, but I don;t think mnost of the other projects do...even if they do, it only takes one sensitive operation without project_id in the URL to break the pattern. BTW, I sent the following email in this list. I think I found right person who can answer my question? :-) http://lists.openstack.org/pipermail/openstack-dev/2015-May/063915.html - HTTP_X_SERVICE_ROLES handling in _checks.py I've missed there there was another push for Service specif roles out there. We've been trying to make the concpet slighly more general by saying that we were going to namespace roles, and that a Service would be one potential namwspacing. Henry Nash had proposed Domain Specific roles, in case you were wondering what else would need to be namespaced. https://review.openstack.org/#/c/133855/ Thanks in advance, Hisashi Osanai __ OpenStack Development Mailing 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][magnum] Medical semi-emergency with my tooth
Hey Kolla cats (and Magnum cats), I have a tooth infection, which isn’t super serious, but the pain levels are about a 8 out of 10 on the holy fuck scale. As a result, my work is a bit impaired. I may be a bit MIA in the next week while I sort out the medical problem and get my tooth into a manageable state of pain. Please keep working towards getting the blueprints for liberty 1 in a completed state, fixing confirmed bugs, and confirming triaged bugs. Making matters worse for me personally, because our government is a bunch of baby-sitter fail, my Dentist can only call in AC3 over the phone and he is in a different state presently. He said what I really need is oxycodone. He did give me a zpac which may reduce the pain levels by getting rid of the root infection. Anyway, our community is self sufficient so this is more to inform people the Kolla PTL could be MIA over the next week. If I need someone to handle the wendesday meeting I’ll reach out to someone via irc. Regards -steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][OSC] Keystone v3 user create --project $projid does not add user to project?
On 18/06/15 17:58, Dolph Mathews wrote: This was entirely intentional, in order to replace the implicit role assignment behavior in v2 with an explicit behavior in v3. I must admit, this is quite irritating, as the command line client still offers the --project ability; dropping this silently leads to somewhat unexpected results. From a user perspective, I would appreciate a warning in such cases; this is a common pattern everywhere else in OpenStack. Matthias __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][DevStack] Standing on the shoulders of giants - Linux Bridge testing at the gate
Hi, I wanted to give a quick update on the new experimental job for testing the Linux Bridge mechanism driver for Neutron. I believe that there is only one patch that needs to be merged, in order to get the job to a point where we could move from experimental to non-voting. https://review.openstack.org/#/c/192906/ Which is a fix that Dr. Jens Rosenboom authored quite a long time ago, and I stared at for enough time that it is embarrassing - hence the subject line of this message. Dr. Rosenboom did the majority of the work to make all this happen in a previous review, centered around Neutron being the default in DevStack - it just took me a long time to understand what he did - and then shuffle some code around so that configuration that we needed at the gate didn't end up in DevStack, and instead would go into the Linux Bridge job configuration. You can see the results pretty clearly in this review: https://review.openstack.org/#/c/187235/ When that patch is not applied, we fail all the tempest scenario tests. When we apply it, we pass all the tempest scenario tests. Anyway, I'm quite excited about the status of things, and also wanted to publicly thank Dr. Jens Rosenboom for the work that I borrowed from him. -- Sean M. Collins __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Packaged Fuel and Feature Groups
Hi, There are few places where 'feature_groups' is used by Nailgun to turn on/off some experimental stuff. For instance, if there's an 'experimental' word in the 'feature_groups' list then Nailgun will allow you to create new environments based on old releases. Thanks, Igor On Thu, Jun 18, 2015 at 7:29 PM, Alexander Kislitsky akislit...@mirantis.com wrote: Also feature_groups is used for selecting usage statistics collector. If 'mirantis' is in feature_groups we are using one instance of statistics collector and another collector instance in other case. On Thu, Jun 18, 2015 at 7:04 PM, Vitaly Kramskikh vkramsk...@mirantis.com wrote: Hi, Yes, it is possible to change the value of feature_groups after master node installation. Currently it affects only availability of a few options in Fuel UI. 2015-06-18 17:11 GMT+03:00 Aleksandra Fedorova afedor...@mirantis.com: Hi, everyone, could you please clarify a bit about how FEATURE_GROUPS [1] parameter is handled in Fuel. Currently we have it specified at ISO build stage, while from the description of it it looks like it is just a UI switch which doesn't change anything deep inside the code. Can it be changed at master node deployment stage, after master node deployment? Can we use exactly the same nailgun package to install all the different flavors just by changing configuration parameter after package installation? [1] https://ci.fuel-infra.org/job/merged-fuel-specs/Fuel_Development_Specs_build_results/specs/5.1/feature-groups.html#feature-groups -- Aleksandra Fedorova Fuel Devops Engineer bookwar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Vitaly Kramskikh, Fuel UI Tech Lead, Mirantis, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing 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] [Congress] Mid-cycle sprint
Hi, Tim I have looked at the request_fresh_action. One big question is that it requires external services to queue up changes and then call this Congress API at some point. I’m not sure they would buy in this design as many projects have notification mechanism ready now and Ceilometer heavily depends on these notifications. So basically I prefer to use oslo.messaging. But this API is still useful for other external services that don’t use oslo.messaging notification to publish changes and are willing to integrate with Congress this way. Anyway, I can upload my draft bp for review at first. Thanks. BR Zhou Zhenzan From: Tim Hinrichs [mailto:t...@styra.com] Sent: Wednesday, June 17, 2015 21:57 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Congress] Mid-cycle sprint Hi Zhenzan, Yes the oslo.messaging integration task is relevant--oslo.messaging is one way of achieving cross-process, cross-host messaging. So I'll count you as interested for the mid-cycle sprint. Have you looked at the API call that forces a datasource driver to pull immediately? See congress/api/datasource_model.py:DatasourceModel.request_refresh_action. We had envisioned using that to implement a kind of notification from external services as follows. The external service queues up a list of changes and when the queue is long enough runs the API call to force the datasource driver hooked up to that service to pull those changes and then publish them on the bus. So it's not exactly streaming updates from the external service (which is good so that Congress can easily rate-limit updates), but it has almost the same effect. Tim On Tue, Jun 16, 2015 at 6:02 PM Zhou, Zhenzan zhenzan.z...@intel.commailto:zhenzan.z...@intel.com wrote: Hi, Tim Is this the oslo.messaging integration task? I’m interested in participating. Actually I am working on a bp to receive notifications from external services in datasource driver at first. I’m ok to change if the direction is to integrate oslo.messaging thoroughly (even replacing DSE). Thanks. BR Zhou Zhenzan From: Tim Hinrichs [mailto:t...@styra.commailto:t...@styra.com] Sent: Wednesday, June 17, 2015 05:14 To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [Congress] Mid-cycle sprint Hi all, In the last couple of IRCs we've been talking about running a mid-cycle sprint focused on enabling our message bus to span multiple processes and multiple hosts. The message bus is what allows the Congress policy engine to communicate with the Congress wrappers around external services like Nova, Neutron. This cross-process, cross-host message bus is the platform we'll use to build version 2.0 of our distributed architecture. If you're interested in participating, drop me a note. Once we know who's interested we'll work out date/time/location details. Thanks! Tim __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] Specify a domain in mapping rules
I resend it to openstack-operators. I think it is the appropiate mailing
list
2015-06-18 13:04 GMT+02:00 J. Pablo Martín Cobos goi...@gmail.com:
Hi all,
I'm a Python/Django software developer [1]. We have to do an integration
of OpenStack and a Shibboleth IdP in my current project.
This is not a easy feature to configure... but finally we got it :-) Now
we only need specify a domain for the user different to the Federated
default domain. This domain depends on an attribute from the IdP.
Is it possible to get with stable/kilo branch? Is it a feature for the
next release? [2] These are my rules:
[
{
local: [
{
user: {
name: {0},
domain: {
name: {1}
}
}
},
{
group: {
id: 0ff59ec2f97646eb9350fe75478f9600
}
}
],
remote: [
{
type: identity
},
{
type: domain
}
]
}
]
I have tested with a lot of rules with little changes:
domain: {
name: Default
}
or
domain: {
id: default
}
or
domain: {
id: 14321243
}
etc... and this never works :-(
Could you help me?
REF's
1. https://github.com/goinnn
2.
https://github.com/openstack/keystone-specs/blob/master/api/v3/identity-api-v3-os-federation-ext.rst
Thanks a lot!!,
--
Pablo Martín
Software engineer
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] Gerrit based IRC meetings.
Hi All, We've been using the new gerrit based irc-meetings repo for about 3 week now. There have been teething troubles but by and large I think things are going well. People have identified some tooling changes/enhancements that we're workign on, buyt that's another thread. A couple of things have happened that make me feel like we might need to come up with some (and I hesitate to call it policy) conventions? on how changes land in the irc-meetings repo. The first thing is using the review to vote on meeting times. - I'm not certain this is the best workflow but it's something worth palying with. The key is identifying that a review is a suggestion and then identifying when that suggestion becomes golden are the key things. So perhaps if you're looking for votes on a review -W it? Or add a comment like: This a a vote if there are no -1's after $datetime please merge then? Knowning that a meeting change is *correct* / endorsed. - When a Change comes in I do verify that the new time seems to match the project wiki / documentation I can easily find. However it's possible, as an outsider to your project, I may miss sometime and approve a bad change. It isn't great for the calendar to list the wrong meetiung information. I have 2 suggestions: 1) I require the PTL to +1 the meeting change ; or 2) The commit message contains a like to some public log that indicates the change has been discussed. (say an IRC log or mailing list archive) These 2 options aren't exclusive. We could of course just accept mistakes will be made and handle reverts quickly but I don't really like that. Also we need better (some) docs on how to actually schedule a meeting in the new way. I know it isn't radically different to what we all do dya to day but documentation is good. I'll start somethign with the conclusion of this thread. I don't want to make this to hard but I also want to make sure I'm doing the right thing by the community. So thoughts? Yours Tony. pgpHkOVWECexa.pgp 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] [all] [qpid] [zmq] [RabbitMQ] [oslo] Pending deprecation of driver(s).
On 18/06/15 16:37 -0400, Doug Hellmann wrote: Excerpts from Clint Byrum's message of 2015-06-18 12:47:21 -0700: Hello! I know there's been a lot of churn and misunderstanding over the recent devstack changes, so I wanted to make it clear where we're going with messaging drivers now that the policy [1] was approved. According to the policy, drivers need to have at least 60% unit test coverage, and an integration test suite with at least 3 popular OpenStack projects, with preference for Nova, Cinder, and Glance, and individuals who will support said test suite. So, with that, the following is the status of each driver in tree right now: rabbit - 89% Unit test coverage. Being the default in devstack, and the default in nearly every project's config files, this one is heavily integration tested. There are multiple individuals who have proven to be able to debug failures related to RabbitMQ and are well known in the community. +1 qpid - Unit test coverage is at 77%, so it passes that bar. I cannot find any integration testing being done, so it fails that. I also have not found anyone who will step up and support it. So this should be deprecated immediately. +1 - I believe Ken and the other folks interested in this indicated that the AMQP 1.0 driver should replace this one. The qpid driver should be deprecated, I'll be doing so in the next couple of days. Look forward to the patch. Speaking of AMQP 1.0, you don't mention that one (it uses qpid, but is separate from the driver named qpid). I'd like to clarify something about the AMQP 1.0 driver. It's not a direct replacement for the qpidd one because it uses an entirely different protocol that recently became a standard. The reason I mention this is because it doesn't really require qpidd - not the double d - which is the broker daemon in the qpid family. I guess the confusion comes because the library it sits on top off is called qpid-proton. The qpid family is a set of tools that provide messaging capabilities. Among those you find qpidd (broker daemon), qpid-proton (amqp1.0 library), qpid-dispatch (message router). It's confusing indeed. The importance of this distinction is that the amqp1.0 driver in oslo.messaging is intended as a protocol based driver and not targetting any technology. That is to say, that it could be written using a library that is not qpid-proton and it can talk to any message router or message broker that has support for amqp 1.0. The ones we're targetting for the gate are rabbitmq (with the amqp 1.0 plugin enabled) and qpidd. Since we're at it, let me share some updates: The driver unittests now run on every python2 job and the work on python3 is almost done. There's also a functional tests gate like we have for other drivers. The missing bit is an integration gate, which we'll be start working on in the next couple of days. Hope the above helps clarifying confusions around this driver. zmq - Unit test coverage is 74%. There are no currently active integration tests in OpenStack's infrastructure. Several individuals have self identified as being willing to work on creating them. We have not had the conversations yet about ongoing support. I recommend we continue to support their effort to become policy compliant. If that does not solidify by M3 of Liberty, or if the new zmq driver appears with integration tests and support manpower, then we can deprecate at that time. +1 - I know interest has been growing in this, so let's keep it going and see where we end up. There's also the question of _how_ to deprecate them. I figure we should deprecate when the driver is loaded. Is there an existing mechanism that someone can point me to, or should I look at adding that to oslo.messaging/stevedore? Normally we would recommend using versionutils from oslo.log, but we've been trying to avoid making oslo.log a dependency of the oslo libs because it uses some of them and that introduces cycles. Dims had a patch recently that just used a DeprecationWarning, and relied on oslo.log to redirect the warning to the log file. That seems like a good pattern to repeat. Can we use debtcollector to decorate the main driver class? A warning will be printted every time an instance of such class is created (rather than at import time). If we don't want to add a dependency on that, we could just use a DeprecationWarning as Doug mentioned. Doug [1] http://specs.openstack.org/openstack/openstack-specs/specs/supported-messaging-drivers.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- @flaper87 Flavio Percoco pgpRxjxkSBOzd.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage
Re: [openstack-dev] Debian already using Python 3.5: please gate on that
On Jun 19, 2015 1:19 PM, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/18/2015 09:48 PM, Doug Hellmann wrote: Excerpts from Brian Curtin's message of 2015-06-18 13:17:52 -0500: On Thursday, June 18, 2015, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Thomas Goirand's message of 2015-06-18 15:44:17 +0200: Hi! tl;dr: skip this message, the subject line is enough! :) As per the subject line, we already have Python 3.5 in Debian (AFAICT, from Debian Experimental, in version beta 2). As a consequence, we're already running (unit) tests using Python 3.5. Some have failures: I could see issues in ceilometerclient, keystoneclient, glanceclient and more (yes, I am planning to report these issues, and we already started doing so). As Python 3.4 is still the default interpreter for /usr/bin/python3, that's currently fine, but it soon wont be. All this to say: if you are currently gating on Python 3, please start slowly adding support for 3.5, as we're planning to switch to that for Debian 9 (aka Stretch). I believe Ubuntu will follow (as the Python core packages are imported from Debian). 3.5 is still in beta. What's the schedule for an official release from the python-dev team? 3.4 Final is planed for September 13 https://www.python.org/dev/peps/pep-0478/ Based on that, I am confident in sticking with our plan of gating using 3.4 for now and keeping an eye on the 3.5 packages being built by Debian and Canonical. +1. Putting burden on projects to adopt to beta releases of python is unreasonable. Agreed. I also found the tone of the original email misleading. Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVg/nYAAoJEC5aWaUY1u579GoIANYISvCNK/ltfN8rS7W2pkGd k+xPNYFE1aaGIE8wTakrm0dHG3oSFpVVs5FGtiJwvgFz4RyOBPUhiv6prxp7BBvT SqBvaoKdWsptC2BLrNrSRM62b0TTl+n5anpwPzzdiZcPBHfdaIWjrJnSpm4KMA57 HSZfUvBn1Ge8LL9BzZLOTlOdyQ0jDrh2nI8s27JEk/4yJ+tx2gjxZjQ0N2Xs8TGN WJB+qXBGmttAwwf264b9YeNSZIktAwXbLphG2LKaJHOUuP+YwA1wRdfn5MfxOmTs lc2dln7obATwIRZopdDUOIr6ch9KpQUm/Bs29Sdjcg7Vx1RZl2U0o9inscpoHig= =6C1i -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Debian already using Python 3.5: please gate on that
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 18/06/15 21:44, Jeremy Stanley wrote: Based on that, I am confident in sticking with our plan of gating using 3.4 for now and keeping an eye on the 3.5 packages being built by Debian and Canonical. Unless we shift platforms and go back to special-casing Py3K jobs, I expect to see us testing the N release cycle on Python 3.5 in Ubuntu 16.04 LTS but probably not prior unless someone steps up to make it happen differently. That sounds reasonable to me; I spoke with the Python maintainers in our Foundations teams (one of whom also maintains Python in Debian) and the expectation is that they will start doing working this cycle (15.10) but I think its realistic that 16.04 would be the target for a default python 3 switch. As Thomas points out, we have 3.5 in Debian experimental and Ubuntu Wily; at some point in time, Debian/Ubuntu will start doing rebuild testing with these newer versions - we'll feed any bugs/fixes back upstream so hopefully when we get to the 16.04/3.5 testing enablement, it will all *just work*. - -- James Page Ubuntu and Debian Developer james.p...@ubuntu.com jamesp...@debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVhBq5AAoJEL/srsug59jDnQ8P/RMbWz2goTHrWZA/+yzpwtPG GucjSbG8YIPfJFWiAnyOaW3eh+XMrisFvS2QFn+7VBPhrJYZiiTBXAU8rAGZ7sgS q2EGmgzkFXLt/Zsw6ej/3E7cZFTqDOB8mT/9cqvxjsLSZ9ulaOEh02BUJJz+Idez FwEUY9Y0mYmzMLgGQpvDGGox9JlnwzhS4EbSKIafE4+8fzscnyWbVYvnpCXm4Rkb jVupr4isdvdOK/oKog/1CgnjU1WFkBIJxMSl2X7aoSt9gAp4u+6sAVdON50hL6JQ /TEbJIHahtSskmvzw0HMhdYr3XrkVf92RvqGXsbH2Ce/UoMCocqxqedQ8sp0R98u inICxqCoEdjQYMFUJ8QsaYQXaMuQNkKdKYzTPInNCFKxsIqyuDSzJAEe/EyfgRuD Yyt76eEbRoFBtVGCcMbEGby/AAbkMWdRx7hmFpHDLh7VKbTTDwtB83+3qppx5Mia Tz1MTxtd9ggAf/PDRJmbr3y51FXbx4J8e4DNJXI3DNG7Lqakmhx7c8lf7n2tyfBb EBckPcGGEGc5cisVLBdrmVlREVNVM2gTb9Z5Is/Lqgm0n336/fTOmFcduA/litBK EbyYERjhCPuCHPCEF/jYVCzTREJM/S/2Vm5hraVjDaMYqu6O9gysze2pkTuP4L51 Ew8I7sRfTKrLdZFzeU/x =8N/+ -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] [Neutron][DevStack] Standing on the shoulders of giants - Linux Bridge testing at the gate
On Fri, Jun 19, 2015 at 2:20 AM, Sean M. Collins s...@coreitpro.com wrote: Hi, I wanted to give a quick update on the new experimental job for testing the Linux Bridge mechanism driver for Neutron. I believe that there is only one patch that needs to be merged, in order to get the job to a point where we could move from experimental to non-voting. https://review.openstack.org/#/c/192906/ Which is a fix that Dr. Jens Rosenboom authored quite a long time ago, and I stared at for enough time that it is embarrassing - hence the subject line of this message. Dr. Rosenboom did the majority of the work to make all this happen in a previous review, centered around Neutron being the default in DevStack - it just took me a long time to understand what he did - and then shuffle some code around so that configuration that we needed at the gate didn't end up in DevStack, and instead would go into the Linux Bridge job configuration. You can see the results pretty clearly in this review: https://review.openstack.org/#/c/187235/ When that patch is not applied, we fail all the tempest scenario tests. When we apply it, we pass all the tempest scenario tests. Anyway, I'm quite excited about the status of things, and also wanted to publicly thank Dr. Jens Rosenboom for the work that I borrowed from him. Great work Sean and Jens! This is fantastic and helps get us to a point where we're able to test Linuxbridge on parity with OVS. Thanks, Kyle -- Sean M. Collins __ OpenStack Development Mailing 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] [oslo][oslo.service] Bootstrapping oslo.service core
Elena Ezhova and Marian Horban helped get oslo.service off the ground [1] with a lot of testing and are actively coordinating adoption by several projects like Nova, Neutron and Cinder etc. Since we don't have anyone in oslo-service-core at the moment, Let's add them as the initial core members of oslo.service. Thanks, dims [1] http://stackalytics.com/?module=oslo.servicemetric=commitsrelease=liberty -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing 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] [Stackalytics] Complementary projects
Some reasons of having complementary projects in Stackalytics: * to compare efforts in other communities with OpenStack - just to feed curiosity on what is larger OpenStack or Kubernetes? * to light interest to contribute to projects that OpenStack depends on, like OVS and Ansible. * to keep an eye on commercial interest and know who is sponsoring near-by technologies. I agree that adding complementary projects was an authoritarian decision and ready to remove them in the community version if TC decides so. Thanks, Ilya 2015-06-19 10:48 GMT+03:00 Thierry Carrez thie...@openstack.org: Paul Belanger wrote: I am wondering the reason for the complementary projects listing[1] in Stackalytics? Specifically, why does stackalytics-processor import docker and cloudfoundry projects into the stats? [1] http://stackalytics.com/?project_type=complementarymetric=commits It's not a community decision. I'd say it is an editorial decision of the current owner of the project and website. While we are trying to move this project under the Infra project team and the Technical Committee oversight, it is currently still a Stackforge project owned by Mirantis. Personally if we were to move it under Infra I would (1) remove the complementary projects and (2) make sure that whoever wants to reuse stackalytics code to track Docker / CloudFoundry activity can easily do so. -- 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 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Proposing YAMAMOTO Takashi for the Control Plane core team
Congratulations and welcome to the team! Edgar From: Kevin Benton Reply-To: OpenStack Development Mailing List (not for usage questions) Date: Thursday, June 18, 2015 at 3:22 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Proposing YAMAMOTO Takashi for the Control Plane core team It has been a week and I haven't heard any negative feedback. Welcome to the control plane core reviewer team YAMAMOTO Takashi! On Mon, Jun 15, 2015 at 2:52 AM, Oleg Bondarev obonda...@mirantis.commailto:obonda...@mirantis.com wrote: +1 On Mon, Jun 15, 2015 at 12:16 PM, Ihar Hrachyshka ihrac...@redhat.commailto:ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Not on the list either, but I want to +1 what Henry said. Yamamoto's reviews expand to the whole code base and are pretty always *very* usefu l. On 06/12/2015 11:39 PM, Henry Gessau wrote: Although I am not on your list I would like to add my +1! Yamamoto shows great attention to detail in code reviews and frequently finds real issues that were not spotted by others. On Thu, Jun 11, 2015, Kevin Benton blak...@gmail.commailto:blak...@gmail.com wrote: Hello all! As the Lieutenant of the built-in control plane[1], I would like YAMAMOTO Takashi to be a member of the control plane core reviewer team. He has been extensively reviewing the entire codebase[2] and his feedback on patches related to the reference implementation has been very useful. This includes everything ranging from the AMPQ API to OVS flows. Existing cores that have spent time working on the reference implementation (agents and AMQP code), please vote +1/-1 for his addition to the team. Aaron, Gary, Assaf, Maru, Kyle, Armando, Carl and Oleg; you have all been reviewing things in these areas recently so I would like to hear from you specifically. 1. http://docs.openstack.org/developer/neutron/policies/core-reviewers.h tml#core-review-hierarchyhttp://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy 2. http://stackalytics.com/report/contribution/neutron-group/90 Cheers -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVfpgHAAoJEC5aWaUY1u57z40IAL8HpGOEQY7aW1aa39C9ig3Y bNLEabeQ0K5a4+5ynVLIm1sEl4s3GF2r0gCXak9FrkqjHx2r8VeyOx8TqrCj8gX3 +4aHI7n6rJoJtINuTd+bN7T65uaZE86erOcZN+yma5V69ObfIZhIfQKr3BMaBeZT ah5hkUKl88ckLL5zqc0HnT4wcFH/3Ved2fuhP7hw/IEGMFsqTDS8QUTdXg7/OF5t fLt0NluKoOuNMOk8dTqpqtQtiyS/E5TH+miVOzyrUeUmZOEayOO3O2b/9QRkX/hL ijv1j+clT69fhoVAWSaeR7IsXSfqMuKK/hrVtjnyDpBH4KuZnl3QbRpKJ6Yi3bw= =qnTt -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][messaging] Expanding the oslo.messaging core team
Excerpts from Davanum Srinivas (dims)'s message of 2015-06-19 07:46:47 -0400: Hi Team, We have had active and continuing contributions [1] from the following in Blueprints, Reviews, Commits and Summit/Email discussions: * Ken Giusti * Oleksii Zamiatin * Victor Sergeyev Ken and Oleksii are spearheading important drivers that will help expand choices of messaging infrastructure in OpenStack to boot and Victor is helping harden the existing code. So can we please invite them to join the oslo.messaging core team Thanks, Dims [1] http://stackalytics.com/?module=oslo.messaging +1 for all three! __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][oslo.service] Bootstrapping oslo.service core
Excerpts from Davanum Srinivas (dims)'s message of 2015-06-19 08:57:23 -0400: Elena Ezhova and Marian Horban helped get oslo.service off the ground [1] with a lot of testing and are actively coordinating adoption by several projects like Nova, Neutron and Cinder etc. Since we don't have anyone in oslo-service-core at the moment, Let's add them as the initial core members of oslo.service. Thanks, dims [1] http://stackalytics.com/?module=oslo.servicemetric=commitsrelease=liberty +1 -- Thanks to both Elena and Marian for spearheading this work! __ OpenStack Development Mailing 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] [Stackalytics] Complementary projects
On 06/19/2015 09:19 AM, Ilya Shakhat wrote: Some reasons of having complementary projects in Stackalytics: * to compare efforts in other communities with OpenStack - just to feed curiosity on what is larger OpenStack or Kubernetes? * to light interest to contribute to projects that OpenStack depends on, like OVS and Ansible. * to keep an eye on commercial interest and know who is sponsoring near-by technologies. I agree that adding complementary projects was an authoritarian decision and ready to remove them in the community version if TC decides so. Hi Ilya, Personally, I quite like having those complementary projects in Stackalytics, for the reasons you note above. Best, -jay __ OpenStack Development Mailing 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] Gerrit based IRC meetings.
Excerpts from Thierry Carrez's message of 2015-06-19 10:01:46 +0200: Tony Breeds wrote: The first thing is using the review to vote on meeting times. - I'm not certain this is the best workflow but it's something worth palying with. The key is identifying that a review is a suggestion and then identifying when that suggestion becomes golden are the key things. So perhaps if you're looking for votes on a review -W it? Or add a comment like: This a a vote if there are no -1's after $datetime please merge then? I think the irc-meetings review should not be used to decide on a meeting time. Same way you don't post multiple implementations of a feature and vote for the best one. You shouldn't propose something you don't have the intention to see merged, otherwise it's a waste of reviewers time. Yes, doodles are much better for that. Knowning that a meeting change is *correct* / endorsed. - When a Change comes in I do verify that the new time seems to match the project wiki / documentation I can easily find. However it's possible, as an outsider to your project, I may miss sometime and approve a bad change. It isn't great for the calendar to list the wrong meetiung information. I have 2 suggestions: 1) I require the PTL to +1 the meeting change ; or 2) The commit message contains a like to some public log that indicates the change has been discussed. (say an IRC log or mailing list archive) These 2 options aren't exclusive. We could of course just accept mistakes will be made and handle reverts quickly but I don't really like that. I think it's fair to request that the meeting is proposed by the group lead, *or* that the commit message points to reference information that shows that the team lead is fine with it, *or* has the lead +1 on it. As a reviewer, I would prefer that the lead submit the patch or +1 it to avoid any ambiguity with my interpretation of meeting logs. Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Debian already using Python 3.5: please gate on that
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/18/2015 09:48 PM, Doug Hellmann wrote: Excerpts from Brian Curtin's message of 2015-06-18 13:17:52 -0500: On Thursday, June 18, 2015, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Thomas Goirand's message of 2015-06-18 15:44:17 +0200: Hi! tl;dr: skip this message, the subject line is enough! :) As per the subject line, we already have Python 3.5 in Debian (AFAICT, from Debian Experimental, in version beta 2). As a consequence, we're already running (unit) tests using Python 3.5. Some have failures: I could see issues in ceilometerclient, keystoneclient, glanceclient and more (yes, I am planning to report these issues, and we already started doing so). As Python 3.4 is still the default interpreter for /usr/bin/python3, that's currently fine, but it soon wont be. All this to say: if you are currently gating on Python 3, please start slowly adding support for 3.5, as we're planning to switch to that for Debian 9 (aka Stretch). I believe Ubuntu will follow (as the Python core packages are imported from Debian). 3.5 is still in beta. What's the schedule for an official release from the python-dev team? 3.4 Final is planed for September 13 https://www.python.org/dev/peps/pep-0478/ Based on that, I am confident in sticking with our plan of gating using 3.4 for now and keeping an eye on the 3.5 packages being built by Debian and Canonical. +1. Putting burden on projects to adopt to beta releases of python is unreasonable. Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVg/nYAAoJEC5aWaUY1u579GoIANYISvCNK/ltfN8rS7W2pkGd k+xPNYFE1aaGIE8wTakrm0dHG3oSFpVVs5FGtiJwvgFz4RyOBPUhiv6prxp7BBvT SqBvaoKdWsptC2BLrNrSRM62b0TTl+n5anpwPzzdiZcPBHfdaIWjrJnSpm4KMA57 HSZfUvBn1Ge8LL9BzZLOTlOdyQ0jDrh2nI8s27JEk/4yJ+tx2gjxZjQ0N2Xs8TGN WJB+qXBGmttAwwf264b9YeNSZIktAwXbLphG2LKaJHOUuP+YwA1wRdfn5MfxOmTs lc2dln7obATwIRZopdDUOIr6ch9KpQUm/Bs29Sdjcg7Vx1RZl2U0o9inscpoHig= =6C1i -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo][messaging] Expanding the oslo.messaging core team
Hi Team, We have had active and continuing contributions [1] from the following in Blueprints, Reviews, Commits and Summit/Email discussions: * Ken Giusti * Oleksii Zamiatin * Victor Sergeyev Ken and Oleksii are spearheading important drivers that will help expand choices of messaging infrastructure in OpenStack to boot and Victor is helping harden the existing code. So can we please invite them to join the oslo.messaging core team Thanks, Dims [1] http://stackalytics.com/?module=oslo.messaging -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing 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] Adding vif_type to nova
Hi John and others, for my new neutron ml2 driver [3] I depend on a new vif_type in nova being introduced [1]. I also added Sourabh to cc, as he probably tries to achieve the same goal for another driver. I'm also aware of the current discussion regarding vif-plug-script [2]. This approach only covers the plug/unplug methods that are required for a new vif type, but not the generation of the domain.xml. Now I have a couple of questions when it comes to new vif_types for liberty: - Is a spec required for a new vif type, or is it sufficient to propose it via a bug? (This becomes important as next the spec freeze is some time next week). - I really rely on nova vif support for my new driver. Would it be ok to get the get_config_vif_type method merged and for plug/unplug operation jump on the boat of vif-plug-script [2]? To not break the code I might add the plug/unplug methods for my driver as well, but would just pass them. Any logic required would be added in the style of [2] later on. - The vif-plug-script spec [2] does not cover consolidation of the xml-generating get_config_vif_type methods. Each vif_type still requires it's own get_config_vif_type method. But some review comments already point out, that it would make sense to once cover all libvirt interface types in the vif driver. Once that's done and [2] is implemented, vendor could use the new generic types instead of their own types. Would you think it makes sense to set up an effort (bp + spec) to evaluate what this would mean? If so I could start that, even if my stuff gets merged tomorrow. Thanks a lot! [1] https://review.openstack.org/#/c/182280/ [2] https://review.openstack.org/#/c/162468/ [3] https://review.openstack.org/#/c/189644/ -- Andreas (IRC: scheuran) __ OpenStack Development Mailing 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] [Stackalytics] Complementary projects
Paul Belanger wrote: I am wondering the reason for the complementary projects listing[1] in Stackalytics? Specifically, why does stackalytics-processor import docker and cloudfoundry projects into the stats? [1] http://stackalytics.com/?project_type=complementarymetric=commits It's not a community decision. I'd say it is an editorial decision of the current owner of the project and website. While we are trying to move this project under the Infra project team and the Technical Committee oversight, it is currently still a Stackforge project owned by Mirantis. Personally if we were to move it under Infra I would (1) remove the complementary projects and (2) make sure that whoever wants to reuse stackalytics code to track Docker / CloudFoundry activity can easily do so. -- 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
[openstack-dev] [api] [all] To changes-since or not to changes-since
There's an open question in the API-WG on whether to formalize or otherwise enshrine the concept of a changes-since query parameter on collection oriented resources across the projects. The original source of this concept is from Nova's API: http://docs.openstack.org/developer/nova/v2/polling_changes-since_parameter.html There are arguments for and against but we've been unable to reach a consensus so the agreed next step was to bring the issue to the mailing list so more people can hash it out and provide their input. The hope is that concerns or constraints that those in the group are not aware of will be revealed and a better decision will be reached. The basic idea of changes-since is that it can be used as a way to signal that the requestor is doing some polling and would like to ask Give me stuff that has changed since the last time I checked. As I understand it, for the current implementations (in Nova and Glance) this means including stuff that has been deleted. Repeated requests to the resource with a changes-since parameter gives a running report on the evolving state of the resource. This is intended to allow efficient polling[0]. The pro camp on this likes it because this is very useful and quite humane: The requestor doesn't need to know the details of how the query is is implemented under the hood. That is, if there are several timestamps associated with the singular resources in the collection which of those are used for time comparison and which attributes (such as state with a value of deleted) are used to determine if a singular resource is included. The service gets to decide these things and in order for efficient polling to actually be achieved it needs to do in order to make effective queries of the data store. The con camp doesn't like it because it introduces magic, ambiguity and inconsistency into the API (when viewed from a cross-project perspective) and one of the defining goals of the working group is to slowly guide things to some measure of consistency. The alternate approach is to formulate a fairly rigorous query system for both filtering[1] and sorting[2] and use that to specify explicit queries that state I want resources that are newer than time X in timestamp attribute 'updated_at' _and_ have attribute 'state' that is one of 'foo', 'bar' or 'baz'. (I hope I have represented the two camps properly here and not introduced any bias. Myself I'm completely on the fence. If you think I've misrepresented the state of things please post a clarifying response.) The questions come down to: * Are there additional relevant pros and cons for the two proposals? * Are there additional proposals which can address the shortcomings in either? Thanks for your input. [0] Please try to refrain from responses on the line of ha! efficiency! that's hilarious! and ZOMG, polling, that's so last century. Everybody knows this already and it's not germane to the immediate concerns. We'll get to a fully message driven architecture next week. This week we're still working with what we've got. [1] filtering guideline proposal https://review.openstack.org/#/c/177468/ [2] sorting guideline proposal https://review.openstack.org/#/c/145579/ -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __ OpenStack Development Mailing 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][Ironic] Setting IPXE tag for dnsmasq
I'd like to resurrect this thread. The patch has been sitting for quite a while. Since it doesn't modify the responses by default of DHCP messages, I'm inclined to just let it merge for now as a dnsmasq-specific change. Then maybe later we can figure out how to expose this via the dhcp opts API or a config value. If anyone has any concerns with that, please comment on the patch. Cheers, Kevin Benton On Mon, Apr 20, 2015 at 11:05 AM, Sean M. Collins s...@coreitpro.com wrote: Hi, In the following patch, I had a question about setting the IPXE tag by default. https://review.openstack.org/#/c/172040/ Basically, I'm unsure if we want to set this tag by default. I freely admit that I'm not an expert in PXE, but my thinking is that rather than enabling it by default, we should use the extra_dhcp_opts API extension to set the IPXE tag. http://specs.openstack.org/openstack/neutron-specs/specs/api/extra_dhcp_options__extra-dhcp-opt_.html Thoughts? -- Sean M. Collins __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Proposal of nova-hyper driver
Hi, all, I would like to propose nova-hyper driver: https://blueprints.launchpad.net/nova/+spec/nova-hyper . * What is Hyper? Put simply, Hyper is a hypervisor-agnostic Docker runtime. It is similar to Intel’s ClearContainer, allowing to run a Docker image with any hypervisor. * Why Hyper driver? Given its hypervisor nature, Hyper makes it easy to integrate with OpenStack ecosystem, e.g. Nova, Cinder, Neutron * How to implement? Similar to nova-docker driver. Hyper has a daemon “hyperd” running on each physical box. hyperd exposed a set of REST APIs. Integrating Nova with the APIs would do the job. * Roadmap Integrate with Magnum Ironic. Appreciate for comments and inputs! Thanks,Peng - Hyper - Make VM run like Container__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo.messaging][zeromq] Next step
Flavio Percoco wrote: There's a 95% of deployments using rabbit not because rabbit is the best solution for all OpenStack problems but because it was the one that works best now. The lack of support on other drivers caused this and as long this lack of support on such drivers persist, it won't change. There is 95% of deployments using rabbit because RabbitMQ serves the middle of the Bell curve of the use cases perfectly well. For OpenStack to be ubiquitous, we need to extend beyond our comfort zone of use cases and support technology that will let us address those. I see zmq has an enabler for that: it will solve other classes of problems triggered by extreme use cases. So yes, obviously RabbitMQ dominance should (and will naturally) drive the development and maintenance efforts. But we should at least try to not make the lives of those who explore new trails (and reach to new use cases) miserable. -- Thierry Carrez (ttx) signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Gerrit based IRC meetings.
Tony Breeds wrote: The first thing is using the review to vote on meeting times. - I'm not certain this is the best workflow but it's something worth palying with. The key is identifying that a review is a suggestion and then identifying when that suggestion becomes golden are the key things. So perhaps if you're looking for votes on a review -W it? Or add a comment like: This a a vote if there are no -1's after $datetime please merge then? I think the irc-meetings review should not be used to decide on a meeting time. Same way you don't post multiple implementations of a feature and vote for the best one. You shouldn't propose something you don't have the intention to see merged, otherwise it's a waste of reviewers time. Knowning that a meeting change is *correct* / endorsed. - When a Change comes in I do verify that the new time seems to match the project wiki / documentation I can easily find. However it's possible, as an outsider to your project, I may miss sometime and approve a bad change. It isn't great for the calendar to list the wrong meetiung information. I have 2 suggestions: 1) I require the PTL to +1 the meeting change ; or 2) The commit message contains a like to some public log that indicates the change has been discussed. (say an IRC log or mailing list archive) These 2 options aren't exclusive. We could of course just accept mistakes will be made and handle reverts quickly but I don't really like that. I think it's fair to request that the meeting is proposed by the group lead, *or* that the commit message points to reference information that shows that the team lead is fine with it, *or* has the lead +1 on it. -- Thierry Carrez (ttx) 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] [Nova] Liberty Process, Deadlines and Dates for Nova
A quick bump for this thread because... * liberty-1 is next week * spec freeze is on June 25th * people are unsure about the exception process On 10 June 2015 at 16:45, John Garbutt j...@johngarbutt.com wrote: On 4 June 2015 at 12:42, John Garbutt j...@johngarbutt.com wrote: Hi, Following up from nova-meetings and this summit session: https://etherpad.openstack.org/p/YVR-nova-liberty-process snip With that in mind, does this seem like a good idea? June 12: spec review day (to be confirmed) Note this is happening on Friday, and its confirmed. A day where I hope everyone can help review nova-specs, so we can get as many specs merged before the spec freeze deadline thats coming up soon. We can discuss the details more in the nova-meeting tomorrow. July 10: feature review bash day (to be confirmed) August 7: bug triage day (to be confirmed) September 11: bug review bash day (to be confirmed) I am adding more details here: https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule I have updated the above wiki page. It helps define what all the deadlines mean, and how the exceptions will be processed. As (poorly) advertised, the exception process for the spec freeze should be described here: https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule I suspect it needs some re-writing for clarity, and certainly needs more eyes on it. Do reach out to me with any questions. I noticed I missed out a few dates in the original list, so here is the updated list: * June 23-25: liberty-1 -- spec freeze for L, backlog stays open * July 13-17: non-priority feature proposal freeze * July 21-23: mid-cycle meetup * July 28-30: liberty-2 -- non-priority feature freeze * August 17-21: Feature Proposal Freeze * September 1-3: liberty-3 -- align with string freeze, etc, open specs for M Thanks, John __ OpenStack Development Mailing 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] [qpid] [zmq] [RabbitMQ] [oslo] Pending deprecation of driver(s).
On 06/19/2015 07:14 AM, Flavio Percoco wrote: The qpid family is a set of tools that provide messaging capabilities. Among those you find qpidd (broker daemon), qpid-proton (amqp1.0 library), qpid-dispatch (message router). It's confusing indeed. Apache Qpid is an Apache Software Foundation project aiming to help promote the AMQP protocol by open, collaborative development of libraries, services and tools that use it. It includes many different components now. So the 'qpid' in the name of the different components denotes the community from which they originated. Hopefully that makes it less confusing. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Improvement of the blueprint specs template
Guys, I’d like to ask all Fuel component leads to take a look at the proposed changes and check whether all important sections were added. - romcheg 18 черв. 2015 о 13:14 Roman Prykhodchenko m...@romcheg.me написав(ла): I realize, that discussing this topic in the email is hard. I filed a review request with some changes to the template and invite you folks to take a look at that: https://review.openstack.org/193070 https://review.openstack.org/193070 16 черв. 2015 о 17:08 Roman Prykhodchenko m...@romcheg.me mailto:m...@romcheg.me написав(ла): Hi folks! I was reviewing one of specs for Fuel 7.0 and realized the information there is messed up and it’s pretty hard to put it all together. The reason for that is basically that Fuel is a multicomponent project but the template does not consider that — there is a Proposed change section which is used to define all the changes in the entire project; then there is the API and Data impact sections that are specific to only specific components but still have to be filled in. Since most of new features consider changes to several components I propose to stick to the following structure. It eliminates the need to create several specs to describe one feature and allows to organize everything in one document without messing it up: -- Title -- Excerpt (short version of the Problem description, proposed solution and final results) -- Problem description -- Proposed changes -- Web UI -- Nailgun -- General -- REST API -- Data model -- Astute -- General -- RPC protocol -- Fuel Client -- Plugins -- Impact -- End-user -- QA -- Developer -- Infrastructure (operations) -- Upgrade -- Performance -- Implementation -- Assignee -- Work items -- Web UI -- Nailgun -- Astute -- Fuel Client -- Plugins -- Documentation -- References - romcheg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 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 signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Low Hanging Fruit etherpad
Le 18/06/2015 22:00, melanie witt a écrit : Hi All, I have started an etherpad for tracking low hanging fruit work in Nova: https://etherpad.openstack.org/p/nova-low-hanging-fruit I have linked it on the Nova Mentoring wiki [1] and populated it with a bit of information about the remaining work that needs to be done to convert the rest of the code base to objects. Please feel free to expand the etherpad with other work and information that would help contributors to Nova. [1] https://wiki.openstack.org/wiki/Nova/Mentoring#What_should_I_work_on.3F Thanks, -melanie (irc: melwitt) Sounds pretty awesome. Just one note that we should maybe put some references into a devref section so people coming in could just see how they can help. Also, I have a pending action to document some low-hanging-fruit actions for helping with logging and notifications. I'll draft that out in the etherpad, but in the meantime, if people want to help on that specific subject, they can just ping me on IRC #openstack-nova (bauzas) Thanks again for your work, great reference. -Sylvain __ OpenStack Development Mailing 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] [qa] Status of account creds in the [identity] section of tempest.conf
On Thu, Jun 18, 2015 at 02:13:56PM -0400, David Kranz wrote: We had a discussion about this at the qa meeting today around the following proposal: tl;dr The test accounts feature provides the same functionality as the embedded credentials. We should deprecate the account information embedded directly in tempest.conf in favor of test-accounts, and remove those options at the beginning of the M cycle. We would also rework the non-isolated jobs to use parallel test accounts, with and without admin creds. Starting now, new features such as cleanup and tempest config will not be required to work well (or at all) if the embedded creds are used instead of test accounts. So this was always the long term plan when we started work on the test-accounts mechanism about a year ago. We were holding off on deprecating the original config option based approach until finished the role and network support for test accounts and we had jobs setup using the mechanism. Now that the we finished both role and network support all that's left is setting up the jobs. I don't think there would be any opposition to marking the user and alt user options as deprecated after that. Also leaving in line comments (and maybe emit a warning) marking the non-locking provider mechanism as going away, probably in M. That way we start clearly marking to users that these options will be going away. We have (at least) three use cases that are important, and we want tempest to work well with all of them, but that means something different in each case: 1. throw-away clouds (ci, gate) 2. test clouds 3. production clouds Well, tempest is designed to and tries to support running against any OpenStack cloud. I'm not sure if there are more deployment types than these 3 categories but we should also be supporting those too. For (1), the most important thing is that failing tests not cause false negatives in other tests due to re-using a tenant. This makes tenant isolation continue to be a good choice here, and requiring admin is not an issue. In a perfect world where tempest never left behind any resources regardless of an error at any line of code, test accounts could be used. But we are probably a long way from that. So the cleanup issue here is actually a wider openstack issue. Tempest will *always* call delete on created projects and users. This was a requirement for making test accounts work. (the mechanism for calling delete or freeing a credential set from the list is shared) With tenant isolation this means we'll be deleting a project and users and resources scoped to either may not be deleted first. (if there is a tempest or openstack bug) This is a wider issue for all OpenStack projects that there was a thread a few months ago discussing. For (3), we cannot use admin creds for tempest runs, and test accounts with cleanup allow parallel execution, accepting the risk of a leak causing a false negative. The only way to avoid that risk is to stamp out all leak bugs in tempest. Well depending on the resource in leak in question test accounts would likely catch the issues if there is a list on that resource in a later test. But, I agree, resource leaks have always been treated as bugs and we'll continue to do so. For (2), either isolation or test accounts with cleanup can be used The tempest.conf values are not used in any of these scenarios. Is there a reason they are needed for anything? So the only thing that uses config options for credentials is actually tenant isolation, which uses them to provide admin credentials to do the dynamic creation of accounts. The real advantage of tenant isolation, besides not reusing anything, is actually its configuration simplicity. Using an accounts file can be tricky to use, there are a lot of little gotchas and assumptions in how you write the file. (which we try to document in both the config guide and the sample accounts.yaml file) It also requires a large number of users to be provided depending on the concurrency you're running with. While tenant isolation requires just setting 3-5 config options and you're fine after that. I don't think requiring the use of an accounts file for tenant isolation makes much sense, it's really heavyweight for 1 set of admin creds. Which probably means we should keep the admin user config option around. Although it might make more sense to move those options to the auth section. (and maybe rename them to make it clear that it's for tenant isolation only) -Matt Treinish 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] [Stackalytics] Complementary projects
On 06/19/2015 10:31 AM, Joe Gordon wrote: On Jun 19, 2015 3:56 PM, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com wrote: On 06/19/2015 09:19 AM, Ilya Shakhat wrote: Some reasons of having complementary projects in Stackalytics: * to compare efforts in other communities with OpenStack - just to feed curiosity on what is larger OpenStack or Kubernetes? * to light interest to contribute to projects that OpenStack depends on, like OVS and Ansible. * to keep an eye on commercial interest and know who is sponsoring near-by technologies. I agree that adding complementary projects was an authoritarian decision and ready to remove them in the community version if TC decides so. Hi Ilya, Personally, I quite like having those complementary projects in Stackalytics, for the reasons you note above. Although it's not very useful for 'reviews' http://stackalytics.com/?project_type=complementary Sure, agreed :) I also wonder how well maintained the email mappings are for complementary projects. Good point. I'm sure there can be many improvements made to the support for complementary projects. I was just remarking that I find the information there to be interesting, nothing more. -jay __ OpenStack Development Mailing 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][OSC] Keystone v3 user create --project $projid does not add user to project?
On Fri, Jun 19, 2015 at 12:30 AM, Matthias Runge mru...@redhat.com wrote: On 18/06/15 17:58, Dolph Mathews wrote: This was entirely intentional, in order to replace the implicit role assignment behavior in v2 with an explicit behavior in v3. I must admit, this is quite irritating, as the command line client still offers the --project ability; dropping this silently leads to somewhat unexpected results. From a user perspective, I would appreciate a warning in such cases; this is a common pattern everywhere else in OpenStack. A good place to vent your rage: https://launchpad.net/python-openstackclient __ OpenStack Development Mailing 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][DevStack] Standing on the shoulders of giants - Linux Bridge testing at the gate
- Original Message - On Fri, Jun 19, 2015 at 2:20 AM, Sean M. Collins s...@coreitpro.com wrote: Hi, I wanted to give a quick update on the new experimental job for testing the Linux Bridge mechanism driver for Neutron. I believe that there is only one patch that needs to be merged, in order to get the job to a point where we could move from experimental to non-voting. https://review.openstack.org/#/c/192906/ Which is a fix that Dr. Jens Rosenboom authored quite a long time ago, and I stared at for enough time that it is embarrassing - hence the subject line of this message. Dr. Rosenboom did the majority of the work to make all this happen in a previous review, centered around Neutron being the default in DevStack - it just took me a long time to understand what he did - and then shuffle some code around so that configuration that we needed at the gate didn't end up in DevStack, and instead would go into the Linux Bridge job configuration. You can see the results pretty clearly in this review: https://review.openstack.org/#/c/187235/ When that patch is not applied, we fail all the tempest scenario tests. When we apply it, we pass all the tempest scenario tests. Anyway, I'm quite excited about the status of things, and also wanted to publicly thank Dr. Jens Rosenboom for the work that I borrowed from him. Great work Sean and Jens! This is fantastic and helps get us to a point where we're able to test Linuxbridge on parity with OVS. I hope to have Linux Bridge tested on par with OVS in the upcoming full stack tests as well. Thanks, Kyle -- Sean M. Collins __ OpenStack Development Mailing 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] [all] [qpid] [zmq] [RabbitMQ] [oslo] Pending deprecation of driver(s).
On Fri, Jun 19, 2015 at 2:15 AM Flavio Percoco fla...@redhat.com wrote: On 18/06/15 16:37 -0400, Doug Hellmann wrote: Excerpts from Clint Byrum's message of 2015-06-18 12:47:21 -0700: Hello! I know there's been a lot of churn and misunderstanding over the recent devstack changes, so I wanted to make it clear where we're going with messaging drivers now that the policy [1] was approved. According to the policy, drivers need to have at least 60% unit test coverage, and an integration test suite with at least 3 popular OpenStack projects, with preference for Nova, Cinder, and Glance, and individuals who will support said test suite. So, with that, the following is the status of each driver in tree right now: rabbit - 89% Unit test coverage. Being the default in devstack, and the default in nearly every project's config files, this one is heavily integration tested. There are multiple individuals who have proven to be able to debug failures related to RabbitMQ and are well known in the community. +1 qpid - Unit test coverage is at 77%, so it passes that bar. I cannot find any integration testing being done, so it fails that. I also have not found anyone who will step up and support it. So this should be deprecated immediately. +1 - I believe Ken and the other folks interested in this indicated that the AMQP 1.0 driver should replace this one. The qpid driver should be deprecated, I'll be doing so in the next couple of days. Look forward to the patch. +1 Speaking of AMQP 1.0, you don't mention that one (it uses qpid, but is separate from the driver named qpid). I'd like to clarify something about the AMQP 1.0 driver. It's not a direct replacement for the qpidd one because it uses an entirely different protocol that recently became a standard. The reason I mention this is because it doesn't really require qpidd - not the double d - which is the broker daemon in the qpid family. I guess the confusion comes because the library it sits on top off is called qpid-proton. The qpid family is a set of tools that provide messaging capabilities. Among those you find qpidd (broker daemon), qpid-proton (amqp1.0 library), qpid-dispatch (message router). It's confusing indeed. The importance of this distinction is that the amqp1.0 driver in oslo.messaging is intended as a protocol based driver and not targetting any technology. That is to say, that it could be written using a library that is not qpid-proton and it can talk to any message router or message broker that has support for amqp 1.0. +1 - yeah, we really shouldn't be considering the amqp1 driver as simply the replacement qpid driver - as Flavio points out it has the potential to provide compatibility with other messaging back ends. Clint - can you also include separate metrics for the amqp1 driver? The ones we're targetting for the gate are rabbitmq (with the amqp 1.0 plugin enabled) and qpidd. Since we're at it, let me share some updates: The driver unittests now run on every python2 job and the work on python3 is almost done. There's also a functional tests gate like we have for other drivers. The missing bit is an integration gate, which we'll be start working on in the next couple of days. Hope the above helps clarifying confusions around this driver. zmq - Unit test coverage is 74%. There are no currently active integration tests in OpenStack's infrastructure. Several individuals have self identified as being willing to work on creating them. We have not had the conversations yet about ongoing support. I recommend we continue to support their effort to become policy compliant. If that does not solidify by M3 of Liberty, or if the new zmq driver appears with integration tests and support manpower, then we can deprecate at that time. +1 - I know interest has been growing in this, so let's keep it going and see where we end up. There's also the question of _how_ to deprecate them. I figure we should deprecate when the driver is loaded. Is there an existing mechanism that someone can point me to, or should I look at adding that to oslo.messaging/stevedore? Normally we would recommend using versionutils from oslo.log, but we've been trying to avoid making oslo.log a dependency of the oslo libs because it uses some of them and that introduces cycles. Dims had a patch recently that just used a DeprecationWarning, and relied on oslo.log to redirect the warning to the log file. That seems like a good pattern to repeat. Can we use debtcollector to decorate the main driver class? A warning will be printted every time an instance of such class is created (rather than at import time). If we don't want to add a dependency on that, we could just use a DeprecationWarning as Doug mentioned. Doug [1] http://specs.openstack.org/openstack/openstack-specs/specs/supported-messaging-drivers.html
Re: [openstack-dev] [Keystone][OSC] Keystone v3 user create --project $projid does not add user to project?
Terry Howe terrylh...@gmail.com wrote on 06/19/2015 10:22:51 AM: From: Terry Howe terrylh...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 06/19/2015 10:25 AM Subject: Re: [openstack-dev] [Keystone][OSC] Keystone v3 user create --project $projid does not add user to project? On Fri, Jun 19, 2015 at 12:30 AM, Matthias Runge mru...@redhat.com wrote: On 18/06/15 17:58, Dolph Mathews wrote: This was entirely intentional, in order to replace the implicit role assignment behavior in v2 with an explicit behavior in v3. I must admit, this is quite irritating, as the command line client still offers the --project ability; dropping this silently leads to somewhat unexpected results. From a user perspective, I would appreciate a warning in such cases; this is a common pattern everywhere else in OpenStack. A good place to vent your rage: https://launchpad.net/python-openstackclient I don't think OSC is the place to vent, we are simply following the APIs [0] and python clients [1]. It's a valid option for setting a default project. The behavior of the --project parameter changed from v2 to v3. In v2.0 it used to imply a _member_ role in that project. Now, in v3, it sets a default project that the user can leverage at authentication time [2]. [0] http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3.html#create-user [1] https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/v3/users.py#L51 [2] https://github.com/openstack/keystone/blob/master/keystone/auth/controllers.py#L413-L431 Thanks, Steve Martinelli OpenStack Keystone Core __ OpenStack Development Mailing 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] [Stackalytics] Complementary projects
On Jun 19, 2015 3:56 PM, Jay Pipes jaypi...@gmail.com wrote: On 06/19/2015 09:19 AM, Ilya Shakhat wrote: Some reasons of having complementary projects in Stackalytics: * to compare efforts in other communities with OpenStack - just to feed curiosity on what is larger OpenStack or Kubernetes? * to light interest to contribute to projects that OpenStack depends on, like OVS and Ansible. * to keep an eye on commercial interest and know who is sponsoring near-by technologies. I agree that adding complementary projects was an authoritarian decision and ready to remove them in the community version if TC decides so. Hi Ilya, Personally, I quite like having those complementary projects in Stackalytics, for the reasons you note above. Although it's not very useful for 'reviews' http://stackalytics.com/?project_type=complementary I also wonder how well maintained the email mappings are for complementary projects. Best, -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic][Horizon][Tuskar-ui] Making a dashboard for Ironic
Hrm, well, this is a discussion I was hoping to have in Vancouver, but we never got around to it. I feel we actually want three projects. One, which permits a standalone Ironic Dashboard. One, which integrates Ironic with Horizon. One, which contains as much common code as possible. And, potentially, one that contains as much common code between, say, an ironic shared library and a glance shared library. Because Ironic isn't the only project out there that may and I know this is CRAZY... but there are other projects that MAY not want to be dependent on other projects. So while I do not have a problem with an ironic dashboard inside horizon's angular dashboard, and I do not have a problem working on that, I'm rather concerned about the feasibility of that right now. And the reason's really, really simple: The plumbing's not there yet. What I mean by that is that the dependency mechanism by which all these projects could chain off of each other isn't there. And the mechanism by which these projects are published from infra isn't there. And we haven't quite agreed on even common style rules yet. And a long list of other necessary things that come from having to catch up with K-#-of-releases-in-years of Infra having a full team of engineers working on building up a testing infrastructure. And, while I understand that Hey why don't we just start one project and split it apart when need arises is a valid approach, or What's wrong with horizon is a likely question, I personally feel that they're all hacks, and as engineers of enterprise software we have to be more meticulous than that. But: Do I want to stand in the way of an ironic-dashboard because all of these plumbing requirements? No. But please understand that until that plumbing is in place, and until we reach consensus on how we do javascript in openstack, any decisions you make on technology choice, architecture, project structure, and implementation is about 75% likely to have to be redone, and I will very happily -1 every patch of yours and tell you so. And I'm working on that plumbing. So if you want to help, here's my current list of TODO Items that I have to complete before I become a new dad in early september. - Land CORS support in our API's. - Fix all the linting errors in Horizon. This will permit horizon to gate on javascript style guidelines, and finally use the javascript-jobs template in the gate. - This will permit merlin to adopt the javascript style guidelines, and run them in the gate. - This will also permit angular-ironic-dashboard-rainbows-and-unicorns to adopt those guidelines, and run them in the gate. - We need to figure out how to gate a javascript API library integration test against devstack. And then we need to standardize that build across all projects that use the javascript builds. - We need to figure out how we make sure library dependencies are shared between projects, so our versions don't get out of sync (i.e. I can import things from the ironic shared lib into both horizon and ironic-webclient). - We need to talk to the infra team about publishing released javascript library tarballs to an authoritative, stable Repository. The reason for this is that Infra doesn't like skynet, and therefore doesn't let zuul or any of our other tools push code back to our git repositories in an automated fashion. So the javascript-world's use of Git-As-The-Authoritative-Source-Of-Everything is unlikely to work for us, so we have to publish tarballs (alternative solutions to this are appreciated). - We need to teach both bower and npm to consume our tarballs. This isn't strictly a need, as we can just express our dependencies as absolute URI's _to_ those tarballs, but if the world at large is interested in starting to build their own Apps On OpenStack using the javascript API's, that's something we want to do. - We need to have a serious discussion about ACL's in gerrit, as well as what it means to be a core on Horizon, vs a core on an oslo-like library that is consumed by horizon and other projects. Michael On Thu, Jun 18, 2015 at 5:48 PM niuzhenguo niuzhen...@huawei.com wrote: Hi Thai Q Tran, Thanks for the links about the Angular Dashboard, I agree with starting with the new angular horizon, will begin to draft a init repo of the new ironic-dashboard. And maybe can work with Krotscheck together. And as Andreas Jaeger comments here [1], he suggested to push ironic-dashboard in the openstack namespace instead of stackforge, and have a separate core team, needs Ironicers chime in here. [1] https://review.openstack.org/#/c/191131/ Regards -zhenguo *From:* Thai Q Tran [mailto:tqt...@us.ibm.com] *Sent:* Friday, June 19, 2015 6:36 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Ironic][Horizon][Tuskar-ui] Making a dashboard for Ironic Hi Zhengou, I think it make sense to start with the angular version. It's true that we don't
Re: [openstack-dev] [os-ansible-deployment] Core team nomination
Please join me in welcoming Ian Cordasco to the `os-ansible-deployment` core team! ?? -- Kevin Carter From: Hugh Saunders h...@wherenow.org Sent: Thursday, June 18, 2015 10:00 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [os-ansible-deployment] Core team nomination +1 -- Hugh Saunders On 13 June 2015 at 18:18, Kevin Carter kevin.car...@rackspace.commailto:kevin.car...@rackspace.com wrote: Hello, I would like to nominate Ian Cordasco (sigmavirus24 on IRC) for the os-ansible-deployment-core team. Ian has been contributing to the OSAD project for some time now and has always had quality reviews[0], he's landing great patches[1], he's almost always in the meetings, and is simply an amazing person to work with. His open source first attitude, security mindset, and willingness to work cross project is invaluable and will only stand to better the project and the deployers whom consume it. Please respond with +1/-1s and or any other concerns. As a reminder, we are using the voting process outlined at [ https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess ] to add members to our core team. Thank you. -- Kevin Carter [0] https://review.openstack.org/#/q/status:closed+owner:%22Ian+Cordasco%22+project:stackforge/os-ansible-deployment,n,z [1] https://review.openstack.org/#/q/status:merged+owner:%22Ian+Cordasco%22+project:stackforge/os-ansible-deployment,n,z __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] [oslo][oslo.service] Bootstrapping oslo.service core
Sounds great to me, welcome! Davanum Srinivas wrote: Elena Ezhova and Marian Horban helped get oslo.service off the ground [1] with a lot of testing and are actively coordinating adoption by several projects like Nova, Neutron and Cinder etc. Since we don't have anyone in oslo-service-core at the moment, Let's add them as the initial core members of oslo.service. Thanks, dims [1] http://stackalytics.com/?module=oslo.servicemetric=commitsrelease=liberty __ OpenStack Development Mailing 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] [qpid] [zmq] [RabbitMQ] [oslo] Pending deprecation of driver(s).
Flavio Percoco wrote: On 18/06/15 16:37 -0400, Doug Hellmann wrote: Excerpts from Clint Byrum's message of 2015-06-18 12:47:21 -0700: Hello! I know there's been a lot of churn and misunderstanding over the recent devstack changes, so I wanted to make it clear where we're going with messaging drivers now that the policy [1] was approved. According to the policy, drivers need to have at least 60% unit test coverage, and an integration test suite with at least 3 popular OpenStack projects, with preference for Nova, Cinder, and Glance, and individuals who will support said test suite. So, with that, the following is the status of each driver in tree right now: rabbit - 89% Unit test coverage. Being the default in devstack, and the default in nearly every project's config files, this one is heavily integration tested. There are multiple individuals who have proven to be able to debug failures related to RabbitMQ and are well known in the community. +1 qpid - Unit test coverage is at 77%, so it passes that bar. I cannot find any integration testing being done, so it fails that. I also have not found anyone who will step up and support it. So this should be deprecated immediately. +1 - I believe Ken and the other folks interested in this indicated that the AMQP 1.0 driver should replace this one. The qpid driver should be deprecated, I'll be doing so in the next couple of days. Look forward to the patch. Speaking of AMQP 1.0, you don't mention that one (it uses qpid, but is separate from the driver named qpid). I'd like to clarify something about the AMQP 1.0 driver. It's not a direct replacement for the qpidd one because it uses an entirely different protocol that recently became a standard. The reason I mention this is because it doesn't really require qpidd - not the double d - which is the broker daemon in the qpid family. I guess the confusion comes because the library it sits on top off is called qpid-proton. The qpid family is a set of tools that provide messaging capabilities. Among those you find qpidd (broker daemon), qpid-proton (amqp1.0 library), qpid-dispatch (message router). It's confusing indeed. The importance of this distinction is that the amqp1.0 driver in oslo.messaging is intended as a protocol based driver and not targetting any technology. That is to say, that it could be written using a library that is not qpid-proton and it can talk to any message router or message broker that has support for amqp 1.0. The ones we're targetting for the gate are rabbitmq (with the amqp 1.0 plugin enabled) and qpidd. Since we're at it, let me share some updates: The driver unittests now run on every python2 job and the work on python3 is almost done. There's also a functional tests gate like we have for other drivers. The missing bit is an integration gate, which we'll be start working on in the next couple of days. Hope the above helps clarifying confusions around this driver. zmq - Unit test coverage is 74%. There are no currently active integration tests in OpenStack's infrastructure. Several individuals have self identified as being willing to work on creating them. We have not had the conversations yet about ongoing support. I recommend we continue to support their effort to become policy compliant. If that does not solidify by M3 of Liberty, or if the new zmq driver appears with integration tests and support manpower, then we can deprecate at that time. +1 - I know interest has been growing in this, so let's keep it going and see where we end up. There's also the question of _how_ to deprecate them. I figure we should deprecate when the driver is loaded. Is there an existing mechanism that someone can point me to, or should I look at adding that to oslo.messaging/stevedore? Normally we would recommend using versionutils from oslo.log, but we've been trying to avoid making oslo.log a dependency of the oslo libs because it uses some of them and that introduces cycles. Dims had a patch recently that just used a DeprecationWarning, and relied on oslo.log to redirect the warning to the log file. That seems like a good pattern to repeat. Can we use debtcollector to decorate the main driver class? A warning will be printted every time an instance of such class is created (rather than at import time). Seems fair to me: http://docs.openstack.org/developer/debtcollector/api.html#debtcollector.removals.remove (which itself uses a deprecation warning...). If we don't want to add a dependency on that, we could just use a DeprecationWarning as Doug mentioned. Doug [1] http://specs.openstack.org/openstack/openstack-specs/specs/supported-messaging-drivers.html __ OpenStack Development Mailing 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] Liberty Mid Cycle Meetup
Hi everybody, I got confirmation for hosting the mid cycle meetup at the HP Office in Fort Collins on July 21st - 23rd. I’ve put details on the location with a couple nearby hotels on the following ether pad. The room we have reserved can hold about 40 people, but I’ve requested for it to be setup so that we can have a couple different work areas in the room. There will be a u-shape configuration at the front of the room for 20 and another u-shape at the back of the room for 10 to be used for breakout discussions. https://etherpad.openstack.org/p/horizon-liberty-midcycle A question I have is whether we’ll want to have lunch catered or if we’ll want to let everybody out for an hour to get lunch from one of the nearby restaurants. There is a cafeteria on site as well. If we decide to have it catered, I’ll have to know of any special dietary requests. Thanks, Travis __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][messaging] Expanding the oslo.messaging core team
+1 Le 2015-06-19 14:54, Doug Hellmann a écrit : Excerpts from Davanum Srinivas (dims)'s message of 2015-06-19 07:46:47 -0400: Hi Team, We have had active and continuing contributions [1] from the following in Blueprints, Reviews, Commits and Summit/Email discussions: * Ken Giusti * Oleksii Zamiatin * Victor Sergeyev Ken and Oleksii are spearheading important drivers that will help expand choices of messaging infrastructure in OpenStack to boot and Victor is helping harden the existing code. So can we please invite them to join the oslo.messaging core team Thanks, Dims [1] http://stackalytics.com/?module=oslo.messaging +1 for all three! __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][Ironic] Setting IPXE tag for dnsmasq
What does iPXE do exactly?, What are the implications of having this enabled by default? Cheers, Miguel Ángel Kevin Benton wrote: I'd like to resurrect this thread. The patch has been sitting for quite a while. Since it doesn't modify the responses by default of DHCP messages, I'm inclined to just let it merge for now as a dnsmasq-specific change. Then maybe later we can figure out how to expose this via the dhcp opts API or a config value. If anyone has any concerns with that, please comment on the patch. Cheers, Kevin Benton On Mon, Apr 20, 2015 at 11:05 AM, Sean M. Collinss...@coreitpro.com wrote: Hi, In the following patch, I had a question about setting the IPXE tag by default. https://review.openstack.org/#/c/172040/ Basically, I'm unsure if we want to set this tag by default. I freely admit that I'm not an expert in PXE, but my thinking is that rather than enabling it by default, we should use the extra_dhcp_opts API extension to set the IPXE tag. http://specs.openstack.org/openstack/neutron-specs/specs/api/extra_dhcp_options__extra-dhcp-opt_.html Thoughts? -- Sean M. Collins __ OpenStack Development Mailing 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] [Stackalytics] Complementary projects
On 06/19/2015 11:40 AM, Jay Pipes wrote: On 06/19/2015 10:31 AM, Joe Gordon wrote: On Jun 19, 2015 3:56 PM, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com wrote: On 06/19/2015 09:19 AM, Ilya Shakhat wrote: Some reasons of having complementary projects in Stackalytics: * to compare efforts in other communities with OpenStack - just to feed curiosity on what is larger OpenStack or Kubernetes? * to light interest to contribute to projects that OpenStack depends on, like OVS and Ansible. * to keep an eye on commercial interest and know who is sponsoring near-by technologies. I agree that adding complementary projects was an authoritarian decision and ready to remove them in the community version if TC decides so. Hi Ilya, Personally, I quite like having those complementary projects in Stackalytics, for the reasons you note above. Although it's not very useful for 'reviews' http://stackalytics.com/?project_type=complementary Sure, agreed :) I also wonder how well maintained the email mappings are for complementary projects. Good point. I'm sure there can be many improvements made to the support for complementary projects. I was just remarking that I find the information there to be interesting, nothing more. I also find it interesting. I, in fact, added the ansible and python packaging related repos to the list, because I found it interesting. It's also nice to see that we're not completely insular - that we, as OpenStack, also work with others. We have humans working in both openstack and openvswitch, for instance. And who are working in ansible and openstack. Etc. I think that's a great positive thing to be able to highlight - we are, after all, not an island to ourselves, but are part of a larger community. So, my vote will be to keep them. I'm only one vote, of course, but I think it would be a shame to get rid of them. Monty __ OpenStack Development Mailing 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] [QOS] Request for Additional QoS capabilities
Hi John, I guess it totally makes sense as a new type of rule for QoS, once the framework is ready, it could make sense to add a connection per second limit or max connection limit type of rule. John Joyce (joycej) wrote: Gal: I had seen the brute force blueprint and noticed how close the use case was. Can you tell me the current status of the work? Do you feel confident it can get into Liberty? Ideally, we think this fits better with QoS. Also I don’t think of it as providing FWaaS as we see that all VMs would be protected by this when enabled, but maybe that is just terminology. We think these protections are critical so we are more concerned with having the ability to protect against these cases than the specific API or service it falls under. Yes we would be interested in working together to get this pushed through. John From: Gal Sagie [mailto:gal.sa...@gmail.com] Sent: Wednesday, June 17, 2015 12:45 PM To: OpenStack Development Mailing List (not for usage questions) Cc: lionel.zer...@huawei.com; Derek Chamorro (dechamor); Eran Gampel Subject: Re: [openstack-dev] [Neutron] [QOS] Request for Additional QoS capabilities Hi John, We were trying to push a very similar spec to enhance the security group API, we covered both DDoS case and another use case for brute force prevention (We did a research to identify common protocols login behaviour in order to identify brute force attacks using iptables) and even some UI work You can view the specs and implementations here: 1) https://review.openstack.org/#/c/184243/ 2) https://review.openstack.org/#/c/154535/ 3) https://review.openstack.org/#/c/151247/ 4) https://review.openstack.org/#/c/161207/ The spec didn't got approved as there is a strong opinion to keep the security group API compatible with Amazon. I think this and your request fits much more into the FWaaS and if this is something you would like to work together on and push i can help and align the above code to use FWaaS. Feel free to contact me if you have any question Thanks Gal. On Wed, Jun 17, 2015 at 6:58 PM, John Joyce (joycej)joy...@cisco.commailto:joy...@cisco.com wrote: Hello everyone: I would like to test the waters on some new functionality we think is needed to protect OpenStack deployments from some overload situations due to an excessive user or DDOS scenario. We wrote this up in the style of an RFE. Please let us know your thoughts and we can proceed with a formal RFE with more detail if there are no concerns raised. *What is being requested* This request is to extend the QOS APIs to include the ability to provide connection rate limiting *Why is it being requested* There are many scenarios where a VM may be intentionally malicious or become harmful to the network due to its rate of initializing TCP connections. The reverse direction of a VM being attacked with an excessive amount of TCP connection requests either intentionally or due to overload is also problematic. *Implementation Choices There might be a number of ways to implement this, but one of the easiest would appear to be to extend the APIs being developed under: https://review.openstack.org/#/c/187513/. An additional rule type “connections per-second” could be added. The dataplane implementation itself may be realized with netfilter and conntrack. *Alternatives It would be possible to extend the security groups in a similar fashion, but due to the addition of rate limiting, QoS seems a more nature fit. *Who needs it* Cloud operators have experienced this issue in real deployments in a number of cases. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best Regards , The G. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Online Migrations.
There are multiple nova objects that each have their own version and each object corresponds to a database model. I think this might be the best solution for being able to determine if rows are migrated or not. My basic thought is that each table has a the corresponding object class noted in the .info dict for the table allowing us to determine what object class should be used to verify migrations. The biggest concern would be to verify that all rows are migrated to a point that they can all be tagged with the latest object version at the time of adding the version tag to each row. Then if this method is to be used we can use this in the future to determine if migrations of a row have completed. -Ph On Jun 16, 2015, at 9:16 AM, Mike Bayer mba...@redhat.com wrote: On 6/15/15 8:34 PM, Philip Schwartz wrote: I discussed this a bit earlier with John and we came up with a thought that I was going to present after getting a little bit more documentation and spec around. With out going into too much detail, here is the basics of the idea. Add a new column to all data models that allow us to inject with insert/update of rows the version of the Nova object it is for. Then we can add logic that prevents the contract from being run till a condition is met for a specific period of time after an object version has been deprecated. Once the depreciation window passes, it would be safe to remove the column form the model and contract the DB. This fits with our current thinking and the ability for conductor to down cast objects to older object versions and best of all, it is easy for us to maintain and access as the version for each row creation has access to the nova object and the version set in the object class. If we set the criteria for breaking backwards compatibility and object downgrading with a new major version `VERSION = ‘2.0’` we know at that point it is safe to remove columns from the model that became deprecated prior to ‘2.0’ and allow the contract to run as long as all rows of data have a version in them of ‘2.0’. This does not have to be a major version and could really just be an arbitrary object version + N that we decide as a community. How much of a 1-1 relationship is there from database table - Nova object ? To what extent does this change enforce that 1-1 vs. remaining agnostic of it? I ask because one of the issues some of us see with the objects approach is that it can be taxing on performance and flexibility if it exposes an API that is too fine-grained and molded to the structure of tables. -Ph On Jun 15, 2015, at 8:06 PM, Mike Bayer mba...@redhat.com wrote: On 6/15/15 6:37 PM, Mike Bayer wrote: On 6/15/15 4:21 PM, Andrew Laski wrote: If I had to visualize what an approach looks like that does this somewhat cleanly, other than just putting off contract until the API has naturally moved beyond it, it would involve a fixed and structured source of truth about the specific changes we care about, such as a versioning table or other data table indicating specific remove() directives we're checking for, and the application would be organized such that it can always get to this information from an in-memory-cached source before it makes decisions about queries. The information would need to support being pushed in from the outside such as via a message queue. This would still not protect against operations currently in progress failing but at least would prevent future operations from failing a first time. Or, what I was thinking earlier before I focused too deeply on this whole thing, you basically get all running applications to no longer talk to the to-be-removed structures at all first, *then* do the contract. That is, you're on version L. You've done your expand, you're running the multi-schema version of the model. All your data is migrated.Now some config flag or something else changes somewhere (still need to work out this part), which says, we're done with all the removed() columns. All the apps ultimately get restarted with this new flag in place - the whole thing is now running without including removed() columns in the model (they're still there in the source code, but as I illustrated earlier, some conditional logic has prevented them from actually being part of the model on this new run). *Then* you run the contract. Then you don't have to worry about runtime failures or tracking specific columns or any of that. There's just some kind of state that indicates, ready for L contract. It's still something of a version but it is local to a single version of the software; instead of waiting for a full upgrade from version L to M, you have this internal state that can somehow move from L(m) to L(c).That is a lot more doable and sane than trying to guess at startup / runtime what columns are being yanked.
Re: [openstack-dev] [Neutron][DevStack] Standing on the shoulders of giants - Linux Bridge testing at the gate
On 06/19/2015 03:20 AM, Sean M. Collins wrote: Hi, I wanted to give a quick update on the new experimental job for testing the Linux Bridge mechanism driver for Neutron. I believe that there is only one patch that needs to be merged, in order to get the job to a point where we could move from experimental to non-voting. https://review.openstack.org/#/c/192906/ Which is a fix that Dr. Jens Rosenboom authored quite a long time ago, and I stared at for enough time that it is embarrassing - hence the subject line of this message. Dr. Rosenboom did the majority of the work to make all this happen in a previous review, centered around Neutron being the default in DevStack That would be eversonice to see, so this is a great step forward to a world of joy and happiness. - it just took me a long time to understand what he did - and then shuffle some code around so that configuration that we needed at the gate didn't end up in DevStack, and instead would go into the Linux Bridge job configuration. You can see the results pretty clearly in this review: https://review.openstack.org/#/c/187235/ When that patch is not applied, we fail all the tempest scenario tests. When we apply it, we pass all the tempest scenario tests. Woohoo! Anyway, I'm quite excited about the status of things, and also wanted to publicly thank Dr. Jens Rosenboom for the work that I borrowed from him. Great job both of you! __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon] [UX] [Glance] Enabling Horizon-Glance images streaming: request for early feedback
Hi folks! Some of you might had hit the problems with uploading large Glance images via Horizon, the problem was so well known that it got its own solution in Horizon settings named HORIZON_IMAGES_ALLOW_UPLOAD. So the exact problem is that large images being uploaded to Glance via Horizon may easily exhaust the place on controller node where Horizon server is located - because any sufficiently large file is put into /tmp folder by Django. It seems that I have found more-or-less decent solution [1], I've tested it with 600MB file and it works. I'd like to ask any of you who are willing to get rid of this issue for some early technical feedback. Well, the tests are still failing, I'm aware of this - just want to know that I'm heading in a right direction. Another issue that may be exposed with this solution is how the long-running requests in Horizon should be done from the UX point of view. If an asynchronous request that takes ~several hours to complete needs the Horizon page to remain opened, how should we prevent the user from leaving that page? [1] https://review.openstack.org/#/c/166969 __ OpenStack Development Mailing 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] [qpid] [zmq] [RabbitMQ] [oslo] Pending deprecation of driver(s).
Excerpts from Flavio Percoco's message of 2015-06-19 08:14:49 +0200: On 18/06/15 16:37 -0400, Doug Hellmann wrote: Excerpts from Clint Byrum's message of 2015-06-18 12:47:21 -0700: Hello! I know there's been a lot of churn and misunderstanding over the recent devstack changes, so I wanted to make it clear where we're going with messaging drivers now that the policy [1] was approved. According to the policy, drivers need to have at least 60% unit test coverage, and an integration test suite with at least 3 popular OpenStack projects, with preference for Nova, Cinder, and Glance, and individuals who will support said test suite. So, with that, the following is the status of each driver in tree right now: rabbit - 89% Unit test coverage. Being the default in devstack, and the default in nearly every project's config files, this one is heavily integration tested. There are multiple individuals who have proven to be able to debug failures related to RabbitMQ and are well known in the community. +1 qpid - Unit test coverage is at 77%, so it passes that bar. I cannot find any integration testing being done, so it fails that. I also have not found anyone who will step up and support it. So this should be deprecated immediately. +1 - I believe Ken and the other folks interested in this indicated that the AMQP 1.0 driver should replace this one. The qpid driver should be deprecated, I'll be doing so in the next couple of days. Look forward to the patch. Speaking of AMQP 1.0, you don't mention that one (it uses qpid, but is separate from the driver named qpid). I'd like to clarify something about the AMQP 1.0 driver. It's not a direct replacement for the qpidd one because it uses an entirely different protocol that recently became a standard. The reason I mention this is because it doesn't really require qpidd - not the double d - which is the broker daemon in the qpid family. I guess the confusion comes because the library it sits on top off is called qpid-proton. The qpid family is a set of tools that provide messaging capabilities. Among those you find qpidd (broker daemon), qpid-proton (amqp1.0 library), qpid-dispatch (message router). It's confusing indeed. The importance of this distinction is that the amqp1.0 driver in oslo.messaging is intended as a protocol based driver and not targetting any technology. That is to say, that it could be written using a library that is not qpid-proton and it can talk to any message router or message broker that has support for amqp 1.0. The ones we're targetting for the gate are rabbitmq (with the amqp 1.0 plugin enabled) and qpidd. Since we're at it, let me share some updates: The driver unittests now run on every python2 job and the work on python3 is almost done. There's also a functional tests gate like we have for other drivers. The missing bit is an integration gate, which we'll be start working on in the next couple of days. Hope the above helps clarifying confusions around this driver. zmq - Unit test coverage is 74%. There are no currently active integration tests in OpenStack's infrastructure. Several individuals have self identified as being willing to work on creating them. We have not had the conversations yet about ongoing support. I recommend we continue to support their effort to become policy compliant. If that does not solidify by M3 of Liberty, or if the new zmq driver appears with integration tests and support manpower, then we can deprecate at that time. +1 - I know interest has been growing in this, so let's keep it going and see where we end up. There's also the question of _how_ to deprecate them. I figure we should deprecate when the driver is loaded. Is there an existing mechanism that someone can point me to, or should I look at adding that to oslo.messaging/stevedore? Normally we would recommend using versionutils from oslo.log, but we've been trying to avoid making oslo.log a dependency of the oslo libs because it uses some of them and that introduces cycles. Dims had a patch recently that just used a DeprecationWarning, and relied on oslo.log to redirect the warning to the log file. That seems like a good pattern to repeat. Can we use debtcollector to decorate the main driver class? A warning will be printted every time an instance of such class is created (rather than at import time). debtcollector was originally meant to be used for developer-facing deprecations, but if we can make it emit messages indicating the release cycle when the driver is going to be fully dropped, it might be the right answer. If we don't want to add a dependency on that, we could just use a DeprecationWarning as Doug mentioned. The dependencies are only a concern to me if we introduce a cycle, so as long as that doesn't happen I would be fine with us using debtcollector. Doug Doug [1]
Re: [openstack-dev] [all] [qpid] [zmq] [RabbitMQ] [oslo] Pending deprecation of driver(s).
Excerpts from Ken Giusti's message of 2015-06-19 15:01:46 +: On Fri, Jun 19, 2015 at 2:15 AM Flavio Percoco fla...@redhat.com wrote: On 18/06/15 16:37 -0400, Doug Hellmann wrote: Excerpts from Clint Byrum's message of 2015-06-18 12:47:21 -0700: Hello! I know there's been a lot of churn and misunderstanding over the recent devstack changes, so I wanted to make it clear where we're going with messaging drivers now that the policy [1] was approved. According to the policy, drivers need to have at least 60% unit test coverage, and an integration test suite with at least 3 popular OpenStack projects, with preference for Nova, Cinder, and Glance, and individuals who will support said test suite. So, with that, the following is the status of each driver in tree right now: rabbit - 89% Unit test coverage. Being the default in devstack, and the default in nearly every project's config files, this one is heavily integration tested. There are multiple individuals who have proven to be able to debug failures related to RabbitMQ and are well known in the community. +1 qpid - Unit test coverage is at 77%, so it passes that bar. I cannot find any integration testing being done, so it fails that. I also have not found anyone who will step up and support it. So this should be deprecated immediately. +1 - I believe Ken and the other folks interested in this indicated that the AMQP 1.0 driver should replace this one. The qpid driver should be deprecated, I'll be doing so in the next couple of days. Look forward to the patch. +1 Speaking of AMQP 1.0, you don't mention that one (it uses qpid, but is separate from the driver named qpid). I'd like to clarify something about the AMQP 1.0 driver. It's not a direct replacement for the qpidd one because it uses an entirely different protocol that recently became a standard. The reason I mention this is because it doesn't really require qpidd - not the double d - which is the broker daemon in the qpid family. I guess the confusion comes because the library it sits on top off is called qpid-proton. The qpid family is a set of tools that provide messaging capabilities. Among those you find qpidd (broker daemon), qpid-proton (amqp1.0 library), qpid-dispatch (message router). It's confusing indeed. The importance of this distinction is that the amqp1.0 driver in oslo.messaging is intended as a protocol based driver and not targetting any technology. That is to say, that it could be written using a library that is not qpid-proton and it can talk to any message router or message broker that has support for amqp 1.0. +1 - yeah, we really shouldn't be considering the amqp1 driver as simply the replacement qpid driver - as Flavio points out it has the potential to provide compatibility with other messaging back ends. OK, sorry for my confusion on that and thanks to you and Flavio for clarifying. Clint - can you also include separate metrics for the amqp1 driver? The ones we're targetting for the gate are rabbitmq (with the amqp 1.0 plugin enabled) and qpidd. Since we're at it, let me share some updates: The driver unittests now run on every python2 job and the work on python3 is almost done. There's also a functional tests gate like we have for other drivers. The missing bit is an integration gate, which we'll be start working on in the next couple of days. Hope the above helps clarifying confusions around this driver. zmq - Unit test coverage is 74%. There are no currently active integration tests in OpenStack's infrastructure. Several individuals have self identified as being willing to work on creating them. We have not had the conversations yet about ongoing support. I recommend we continue to support their effort to become policy compliant. If that does not solidify by M3 of Liberty, or if the new zmq driver appears with integration tests and support manpower, then we can deprecate at that time. +1 - I know interest has been growing in this, so let's keep it going and see where we end up. There's also the question of _how_ to deprecate them. I figure we should deprecate when the driver is loaded. Is there an existing mechanism that someone can point me to, or should I look at adding that to oslo.messaging/stevedore? Normally we would recommend using versionutils from oslo.log, but we've been trying to avoid making oslo.log a dependency of the oslo libs because it uses some of them and that introduces cycles. Dims had a patch recently that just used a DeprecationWarning, and relied on oslo.log to redirect the warning to the log file. That seems like a good pattern to repeat. Can we use debtcollector to decorate the main driver class? A warning will be printted every time an instance of such class is created (rather than at
Re: [openstack-dev] [os-ansible-deployment] Core team nomination
Thanks everyone! On 6/19/15, 11:52, Kevin Carter kevin.car...@rackspace.com wrote: Please join me in welcoming Ian Cordasco to the `os-ansible-deployment` core team! -- Kevin Carter From: Hugh Saunders h...@wherenow.org Sent: Thursday, June 18, 2015 10:00 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [os-ansible-deployment] Core team nomination +1 -- Hugh Saunders On 13 June 2015 at 18:18, Kevin Carter kevin.car...@rackspace.com wrote: Hello, I would like to nominate Ian Cordasco (sigmavirus24 on IRC) for the os-ansible-deployment-core team. Ian has been contributing to the OSAD project for some time now and has always had quality reviews[0], he's landing great patches[1], he's almost always in the meetings, and is simply an amazing person to work with. His open source first attitude, security mindset, and willingness to work cross project is invaluable and will only stand to better the project and the deployers whom consume it. Please respond with +1/-1s and or any other concerns. As a reminder, we are using the voting process outlined at [ https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess ] to add members to our core team. Thank you. -- Kevin Carter [0] https://review.openstack.org/#/q/status:closed+owner:%22Ian+Cordasco%22+pr oject:stackforge/os-ansible-deployment,n,z https://review.openstack.org/#/q/status:closed+owner:%22Ian+Cordasco%22+p roject:stackforge/os-ansible-deployment,n,z [1] https://review.openstack.org/#/q/status:merged+owner:%22Ian+Cordasco%22+pr oject:stackforge/os-ansible-deployment,n,z https://review.openstack.org/#/q/status:merged+owner:%22Ian+Cordasco%22+p roject:stackforge/os-ansible-deployment,n,z __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] [all] To changes-since or not to changes-since
On Fri, 2015-06-19 at 10:07 +0100, Chris Dent wrote: * Are there additional relevant pros and cons for the two proposals? * Are there additional proposals which can address the shortcomings in either? On the latter question, would using the If-Modified-Since header[1] make any sense as a possible solution? That at least would be a standard HTTP convention for this sort of thing, and tends to match up with the semantics of a changes-since query parameter. [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.25 -- Kevin L. Mitchell kevin.mitch...@rackspace.com Rackspace __ OpenStack Development Mailing 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] [all] To changes-since or not to changes-since
On 6/19/15, 14:26, Kevin L. Mitchell kevin.mitch...@rackspace.com wrote: On Fri, 2015-06-19 at 10:07 +0100, Chris Dent wrote: * Are there additional relevant pros and cons for the two proposals? * Are there additional proposals which can address the shortcomings in either? On the latter question, would using the If-Modified-Since header[1] make any sense as a possible solution? That at least would be a standard HTTP convention for this sort of thing, and tends to match up with the semantics of a changes-since query parameter. First, please use the updated RFC references (https://tools.ietf.org/html/rfc7232#section-3.3) If-Modified-Since does not. That's meant for entire resources. In other words, let's say you're listing images in Glance and you do GET /v2/images And your response has HTTP/1.1 200 OK Last-Modified: some_last_modified_value In the headers, when you do GET /v2/images If-Modified-Since: some_last_modified_value Then you should either get a: HTTP/1.1 204 No Content Or HTTP/1.1 200 OK Last-Modified: new_last_modified_value (all of the images you saw before) In other words, If-Modified-Since is meant purely for the state of the resource. It's main purpose is when used in conjunction with caching. That said, changes-since is more of a delta. If you need an analogy, think of it as an equivalent to $ git log 2015.1.0..stable/kilo It's just the deltas after a certain timestamp. 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] [api][nova][ironic] Microversion API HTTP header
On Wed, Jun 17, 2015 at 7:31 AM Jay Pipes jaypi...@gmail.com wrote: On 06/17/2015 06:30 AM, Lucas Alvares Gomes wrote: overlap there rather than competition), how crazy does it sound if we say that for OpenStack Nova is the compute API and Ironic the Bare Metal API and so on? Would that be an unacceptable power grab? It's not that it's unacceptable, but I think that things weren't projected that way. Jay started this thread with this sentence: To be blunt, Nova is the *implementation* of the OpenStack Compute API. Ironic is the *implementation* of the OpenStack BareMetal API. Which I don't think is totally correct, at least for Ironic. The Ironic's API have evolved and shaped as we implemented Ironic, I think that some decisions we made in the API makes it clear, e.g: * Resources have JSON attributes. If you look at some attributes of the resources you will see that they are just a JSON blob. That's by design because we didn't know exactly how the API should look like and so by having these JSON fields it allows us to easily extend the resource without changing it's structure [1] (see driver_info, instance_info, extra) OK. Nothing wrong with that. * We have a vendor endpoint. This endpoint allows vendor to extend our API to expose new hardware capabilities that aren't present in the core API. Once multiple vendors starts implementing the same feature on this endpoint we then decide whether to promote it to the core API. This is a problem. The above means that there is no single OpenStack BareMetal API. This means developers that want to write against an OpenStack BareMetal API cannot rely on different deployments of Ironic exposing the same API. That is a recipe for a lack of interoperability and decreased developer ease of use. Nope - not a problem. Actually it's been really helpful. We've found this to be a better way to implement driver extensions -- it's clearly *not* part of Ironic's API, and it's communicated as such in the API itself. Any standard part of Ironic's functionality is exposed in the standard API, and hardware-specific extensions, which are not supported by enough vendors to be standardized yet, are only exposed through the vendor-specific API endpoint. It's very clear in the REST API what this is -- the end points are, for example, GET /v1/nodes//vendor_passthru/methods POST /v1/nodes//vendor_passthru?method=fooparam=bar GET /v1/drivers//methods ... and so on. This provides a mechanism to discover what resources and methods said hardware vendor exposes in their hardware driver. We have always supported out of tree drivers, and it is possible to upgrade Ironic without upgrading the driver (or vice versa). Also to note, our client library doesn't support any of the vendor-specific methods, and never will. It only supports Ironic's API's ability to *discover* what vendor-specific methods that driver exposes, and then to transparently call to them. And none of that is relevant to other OpenStack projects. So if an operator wants to write a custom app that uses foo-vendor's advanced-foo-making capabilities because they only buy Foo hardware -- that's great. They can do that. Presumably, they have a support contract with Foo vendor. Ironic is merely providing the transport between them. * There's a reservation attribute in the Node's resource [1] which valueis the hostname of the conductor that is currently holding an exclusive lock to act upon this node. This is because internally we use a distributed hashing algorithm to be able to route the requests from the API service to a conductor service that is able to manage that Node. And having this field in the API That is just leaking implementation inappropriately out of the public REST API, and shouldn't be encouraged, IMHO. Nova has a number of these leaky parts of its API, too, of course. Just look at the os-guests API extension, which only works when you're using Xen under the hood, thereby leaking implementation details about the underlying infrastructure out through the public REST API. yes, this is leaky in the purest sense, but remember that ironic doesn't expose a *public* API. Only operators and other services should be talking directly to it -- and this field was requested by operators who find it helpful to know which service has locked a resource. I don't think that any of those decisions were bad by the way, this have helped us a lot to understand how a service to manage Bare Metal machines should looks like, and we have made wrong decisions too (You can get the same information by GET'ing different endpoints in the API, the Chassis resources currently have no usage apart from logically grouping nodes, etc...) Sure, all APIs have warts :) But the warts aren't an excuse to delay plugging up those leaks. So back to the topic. if we are removing the project name from the Header to facilitate another
Re: [openstack-dev] [all] FYI - dropping non RabbitMQ support in devstack
On 06/19/2015 03:16 PM, Ken Giusti wrote: I've already +1'd this patch - timing issues aside - I think this is a Good Thing from a developer's point of view. Particularly, my own selfish point of view :) I envision the ability to support multiple different messaging services via the amqp1 driver. Having to keep devstack updated with an array of supported configurations is gonna be a nightmare for all involved. I'd much rather have a small independent plugin to work on rather than having to get every change included into devstack proper. And thanks to Sean's excellent example I've started a plugin for the amqp1.0 driver (totally untested at this point), so we'll have that covered [0]. Thanks Sean! Neat! That said, the only concern I have with this patch is whether it will result in a less well-tested oslo.messaging. It shouldn't. One of the reasons the timing seemed appropriate here is that with the move by the O.M. to own their own setup for services in their functional tree, to the best of my knowledge there are no upstream test jobs using this code to gate project changes. Part of the reason for starting this email thread was to let any that were missed speak up so we could address it. You can use devstack plugins in gate jobs by simply adding 2 additional lines to your project test job definition. I've got a reorganized documentation patch to the devstack repo up for review that hopefully makes that even clearer - https://review.openstack.org/#/c/193519/2/doc/source/plugins.rst,cm (section starts at L199). This is the way that many official OpenStack projects, such as Trove, Zaqar, and Magnum test themselves today, and more and more things are moving to that model. It's really the only sustainable way to support a big OpenStack ecosystem. -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
[openstack-dev] [Ceilometer] Liberty Mid Cycle Virtual Meetup
Hi everyone, In this week's Ceilometer IRC meeting, we took a vote[1] and decide that we will have a *virtual* mid-cycle meetup for Liberty cycle. To figure out the convenient dates we created a doodle[2]. Please take a vote at your earliest, so we can settle on a date and get the rest of the details sorted out. Thanks, ~ Pradeep [1] http://eavesdrop.openstack.org/meetings/ceilometer/2015/ceilometer.2015-06-18-15.05.log.html [2] http://doodle.com/6vfksdu38wcwqqd3 __ OpenStack Development Mailing 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][ml2] - generic port binding for ml2 and dvr
Hi Rob Kukura, We are seeing an issue in the ML2 device_context that was modified by you in a recent patch to get everything from the PortContext instead of the DVR context. Right now the PortContext does not seem to return the DVRbinding status, but just returns the PortContext and it errors out, since the PortContext does not have the attribute status. https://bugs.launchpad.net/neutron/+bug/1465434 The error is seen when you try to update a distributed virtual router interface. It errors out in port_update_postcommit. You have mentioned in your TODO comments that it would be addressed by the bug 1367391, but I still see a patch in WIP waiting for review. Can you take a look at this bug please. Thanks. Swaminathan Vasudevan Systems Software Engineer (TC) HP Networking Hewlett-Packard 8000 Foothills Blvd M/S 5541 Roseville, CA - 95747 tel: 916.785.0937 fax: 916.785.1815 email: swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic][Horizon][Tuskar-ui] Making a dashboard for Ironic
Hi all, I'm glad that by asking the ironic-dashboard creators to propose their project to ironic initially (rather than stackforge) we have prompted this conversation. We now know that two independent groups of people have created standalone ironic dashboards, neither of which is currently part of an OpenStack project. We have an opportunity for those teams to begin collaborating now. I would encourage them to do so, along with both the Ironic and Horizon teams, on a path forward. Let's end the talk of -1ing someone's every patch and instead avail ourselves of one of the many ways in our community we can achieve and record consensus. Michael, you have a plan with a number of steps, one of which is already an approved cross-project spec. Perhaps that is a good starting point for this discussion. -Jim __ OpenStack Development Mailing 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] FYI - dropping non RabbitMQ support in devstack
I've already +1'd this patch - timing issues aside - I think this is a Good Thing from a developer's point of view. Particularly, my own selfish point of view :) I envision the ability to support multiple different messaging services via the amqp1 driver. Having to keep devstack updated with an array of supported configurations is gonna be a nightmare for all involved. I'd much rather have a small independent plugin to work on rather than having to get every change included into devstack proper. And thanks to Sean's excellent example I've started a plugin for the amqp1.0 driver (totally untested at this point), so we'll have that covered [0]. Thanks Sean! That said, the only concern I have with this patch is whether it will result in a less well-tested oslo.messaging. O.M. is supposed to be an abstraction of the messaging bus - it's not just RPC and Notifications over RabbitMQ, is it? How do we validate that abstraction if we don't thoroughly integration test O.M. over multiple different drivers/backends? Other folks have already raised the issue of rabbit-specific behaviors likely leaking through the API, especially with respect to failure scenarios. If we make it harder to run integration tests over anything but the rabbit driver, then we risk breaking that abstraction in such a way that using anything _other_ than rabbit will be practically impossible. [0] https://github.com/kgiusti/amqp1-devstack On Thu, Jun 18, 2015 at 12:28 PM Clint Byrum cl...@fewbar.com wrote: Excerpts from Sean Dague's message of 2015-06-18 07:09:56 -0700: On 06/18/2015 09:54 AM, ozamiatin wrote: Hi Sean, Thanks a lot for the plugin! I was a little bit confused with a commit message and dropping of drivers support. It turns really not so hard to test zeromq driver with plugin. Yes, that was the design goal with the whole plugin mechanism. To provide an experience that was so minimally different from vanilla devstack, that most people would never even notice. It's honestly often easier to explain to people how to enable a service via a plugin than the config variables in tree. +1 So I have no objections any more and removing my -1. Cool, great. It would be great if you or someone else could post a review to pull this code into gerrit somewhere. You'll need the code in gerrit to use it in devstack-gate jobs, as we don't allow projects outside of gerrit to be cloned during tests. But I also agree with Doug Hellmann and other speakers that we should not make such changes so fast. The reason I didn't think the time table was unreasonable was how quick this transition could be made, and how little code is needed to make one of these plugins. And the fact that from there on out you get to be in control of landing fixes or enhancements for your backend on the timetable that works for you. It will make getting the devstack-gate jobs working reliably a lot simpler and quicker for your team. Agreed on all points. I believe that the mistake was simply that there wasn't any need to hold hands for those who we are enabling to move faster and more independently. We do, in fact, need to transfer ownership gracefully. Thanks so much for writing the plugin for zmq, that is a huge win for zmq developers. I can't speak for oslo directly, but it seems like that plugin should land under oslo's direct stewardship and then we can move forward with this. __ OpenStack Development Mailing 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
