Re: [openstack-dev] [Neutron][QoS] Pod time at Paris Summit
Hi Sean, Is there any chance to change this time slot? Unfortunately, I won't be there on Friday. BR, Irena -Original Message- From: Collins, Sean [mailto:sean_colli...@cable.comcast.com] Sent: Thursday, October 30, 2014 5:50 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][QoS] Pod time at Paris Summit I have reserved the 2:35 slot for Friday. https://etherpad.openstack.org/p/neutron-kilo-meetup-slots -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA][Tempest] Gap analysis for using Tempest in production environments
Hello, it is the really important design session, because we need to break the ice and implement several good ideas, which we have. The first one is https://review.openstack.org/#/c/94473, we have the blueprint for this spec and one commit https://review.openstack.org/#/c/75425 in Abandoned state. Can we continue to work on this commit or we need to redesign it and make new commits? The other specs which we also can discuss on this design session (added to etherpad): - https://review.openstack.org/#/c/86967/ - https://review.openstack.org/#/c/89322/ - https://review.openstack.org/#/c/92804/ and again, we need to update them, review and merge (if we want to see them in Tempest). We are using Tempest tests for verification of different OpenStack clouds and we really have issues with many custom configuration files and additional scripts, which allow to configure OpenStack before the tests. I like the idea, which Boris and Andrey described in https://review.openstack.org/#/c/94473 and I want to participate in implementation of this feature and use it to automate OpenStack clouds verification on many projects. I hope we will discuss this spec on the design session and will update and merge it soon. By the way, could you please add the link to etherpad [2] to the event description [1], it will help to find the correct link from mobile devices. Thank you! On Fri, Oct 31, 2014 at 4:23 AM, Masayuki Igawa masayuki.ig...@gmail.com wrote: Hi everyone, I'd like to advertise the session[1] and gather ideas before we will start the session to make it more productive. So please put your ideas for this topic on the pad[2] if you have ideas. I think the goal of this session is to make decisions what we should do or not in Kilo development cycle for filling the gap. And that will be an input to make blurprints. [1] http://kilodesignsummit.sched.org/event/6d91b3205804c930c2a067b23e7aab76#.VErHcH96c-U [2] https://etherpad.openstack.org/p/kilo-summit-gap-analysis-tempest-in-production Thanks, -- Masayuki Igawa ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Timur, Senior QA Engineer OpenStack Projects Mirantis Inc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] MOS Infra weekly report (29 Oct 2014 - 31 Oct 2014)
On 10/31/2014 05:03 PM, Sergey Lukjanov wrote: Heh, wrong mailing list :( Now I know your sekrits... On Fri, Oct 31, 2014 at 7:02 PM, Sergey Lukjanov slukja...@mirantis.com wrote: Hi colleagues, here you can find the weekly report for MOS Infra activity - https://mirantis.jira.com/wiki/display/MOSI/2014/10/31/MOSI+Weekly+Report%2C+Phase+%231%2C+29+Oct+2014+-+31+Oct+2014 Please, note that it includes the previous three days, previous reports could be found in the MOSI space blog - https://mirantis.jira.com/wiki/pages/viewrecentblogposts.action?key=MOSI Thanks. -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Principal Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Cross distribution talks on Friday
Hi, I was wondering if some distribution OpenStack package maintainers would be interested to have some cross-distribution discussion on Friday, during the contributors sessions. I'll be happy to discuss with Ubuntu people, but not only. I'd like to meet also guys working with RedHat and Gentoo. I'm sure we may have some interesting things to share. OpenStack release management team would also be welcome. If you are interested, please reply to this mail. Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [QA][Tempest] Gap analysis for using Tempest in production environments
Hi Timur, Thank you for your reply and adding interesting topics! I'll look at it. By the way, could you please add the link to etherpad [2] to the event description [1], it will help to find the correct link from mobile devices. Actually, I don't have the permission to add/change the description on the sched.org. I think Matthew(mtreinish) can do it. Thanks. On Sat, Nov 1, 2014 at 6:21 PM, Timur Nurlygayanov tnurlygaya...@mirantis.com wrote: Hello, it is the really important design session, because we need to break the ice and implement several good ideas, which we have. The first one is https://review.openstack.org/#/c/94473, we have the blueprint for this spec and one commit https://review.openstack.org/#/c/75425 in Abandoned state. Can we continue to work on this commit or we need to redesign it and make new commits? The other specs which we also can discuss on this design session (added to etherpad): https://review.openstack.org/#/c/86967/ https://review.openstack.org/#/c/89322/ https://review.openstack.org/#/c/92804/ and again, we need to update them, review and merge (if we want to see them in Tempest). We are using Tempest tests for verification of different OpenStack clouds and we really have issues with many custom configuration files and additional scripts, which allow to configure OpenStack before the tests. I like the idea, which Boris and Andrey described in https://review.openstack.org/#/c/94473 and I want to participate in implementation of this feature and use it to automate OpenStack clouds verification on many projects. I hope we will discuss this spec on the design session and will update and merge it soon. By the way, could you please add the link to etherpad [2] to the event description [1], it will help to find the correct link from mobile devices. Thank you! On Fri, Oct 31, 2014 at 4:23 AM, Masayuki Igawa masayuki.ig...@gmail.com wrote: Hi everyone, I'd like to advertise the session[1] and gather ideas before we will start the session to make it more productive. So please put your ideas for this topic on the pad[2] if you have ideas. I think the goal of this session is to make decisions what we should do or not in Kilo development cycle for filling the gap. And that will be an input to make blurprints. [1] http://kilodesignsummit.sched.org/event/6d91b3205804c930c2a067b23e7aab76#.VErHcH96c-U [2] https://etherpad.openstack.org/p/kilo-summit-gap-analysis-tempest-in-production Thanks, -- Masayuki Igawa ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Timur, Senior QA Engineer OpenStack Projects Mirantis Inc ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Masayuki Igawa ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] fuel-library merge policy and Fuel CI
On 10/28/2014 02:15 PM, Aleksandra Fedorova wrote: Vitaly, though comments like this are definitely better than nothing, I think we should address these issues in a more formal way. For random failures we have to retrigger the build until it passes. Yes, it could take some time (two-three rebuilds?), but it is the only reliable way which shows that it is indeed random and hasn't suddenly become permanent. If it fails three times in a row, this issue is probably bigger than you think. Should we really ignore/postpone it then? And if it is really the known issue, we need to fix or disable this particular test. And I think that this fix should be merged in the repo via the general workflow. It doesn't only make everything pass the CI properly, it also adds this necessary step where you announce the issue publicly and it gets approved as the official known issue. I would even add certain keyword for the commit message to mark this temporary fixes to simplify tracking. Aleksandra, You are 100% correct here. Under no circumstances should any human be able to merge code into a master source tree. Only the CI system, after a successful run of tests, should be able to merge code into master. If there are, as Vitaly says, issues with a nailgun test that cause random failures, then the test (or nailgun, whichever is the cause) should be fixed ASAP. We deal with similar issues in the main OpenStack gate, and luckily there we don't allow humans to merge code directly into a branch. Only the CI system can do that, which means that although at times we get frustrated developers who must do the recheck dance a bit, there is a forcing function to have developers fix bugs in tests and server code that trigger false failures. All the best, and keep up the good work. -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Cross distribution talks on Friday
On Sat, Nov 01, 2014 at 09:13:21PM +0800, Thomas Goirand wrote: Hi, I was wondering if some distribution OpenStack package maintainers would be interested to have some cross-distribution discussion on Friday, during the contributors sessions. I'll be happy to discuss with Ubuntu people, but not only. I'd like to meet also guys working with RedHat and Gentoo. I'm sure we may have some interesting things to share. OpenStack release management team would also be welcome. If you are interested, please reply to this mail. You might also want to start an etherpad instance with some initial agenda notes and throw the URL here to guage interest. On a related note, a bunch of Fedora/RHEL/CentOS/Scientific Linux packagers are planning[1] to meetup at the summit to discuss RDO project packaging aspects, etc. [1] https://etherpad.openstack.org/p/RDO_Meetup_Summit -- /kashyap ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
+1 to this, with a term limit. Notable that the Debian TC has been discussing term limits for months now, and since DebConf they seem to have gotten much closer to a concrete proposal[1] in the last week or so. Could be worth watching for ideas on how our community might attempt to implement something similar. That is indeed an interesting approach that the Debian folks are considering. So, just to round out this thread, the key questions are: * whether a low declining turnout is a real problem and, if so: * could this have been driven by a weakness in the voting model, and/or the perception of representative balance in the outcomes The options that were mooted on the thread could be ranked in order of how radical they are, and how likely to have an impact: 0. *do nothing* - accept low turnout as a fact of life, or hope that natural factors such as a slowdown in contributor growth will eventually cause it to stabilize. 1. *make a minor concession to proportionality* - while keeping the focus on consensus, e.g. by adopting the proportional Condorcet variant. 2. *weaken the continuity guarantee* - by un-staggering the terms, so that all seats are contested at each election. 3. *go all out on proportionality* - by adopting a faction-oriented voting model, such as STV with simultaneous terms. 4. *ensure some minimal turn-over* - by adopting either traditional term limits, or the more nuanced approach that Jeremy referenced up-thread. If it came down to it, my money would be on #2 or #3 for the reasons stated before. With the added bonus that this would allow TC elections to be viewed more as a plebiscite on some major issue (such as the layering discussions). Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
On 11/01/2014 04:31 PM, Eoghan Glynn wrote: So, just to round out this thread, the key questions are: * whether a low declining turnout is a real problem I'd like to point out that there 580 'regular' contributors at the moment[1], these are the authors of 95% of the OpenStack code. 506 total number of voters. and, if so: * could this have been driven by a weakness in the voting model, and/or the perception of representative balance in the outcomes I would suggest to explore another possible cause: are the elections advertised enough? Is there enough time for developers to understand also this important part of OpenStack and get involved? Do we use all possible channels to communicate the elections and their importance? Thoughts? /stef [1] http://activity.openstack.org/dash/browser/ -- Ask and answer questions on https://ask.openstack.org ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Lightning talks during the Design Summit!
On 10/31/2014 01:01 PM, Ian Wells wrote: Maruti's talk is, in fact, so interesting that we should probably get together and talk about this earlier in the week. I very much want to see virtual-physical programmatic bridging, and I know Kevin Benton is also interested. Arguably the MPLS VPN stuff also is similar in scope. Can I propose we have a meeting on cloud edge functionality? -- Ian. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I am interested in these discussions as well. Chuck Carlino ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints
+1 yep, as an NFV vendor this is how it really works, and no need for an active/standby on ports….does not make sense for this type of deployment scenario. Typically the two or more sets of apps synch together and address the failover/HA, so no need to make this also in the Infra….you gain nothing from doing active-standby port mgmt. in ovs. /Alan From: Ian Wells [mailto:ijw.ubu...@cack.org.uk] Sent: October-31-14 11:37 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints Go read about HSRP and VRRP. What you propose is akin to turning off one physical switch port and turning on another when you want to switch from an active physical server to a standby, and this is not how it's done in practice; instead, you connect the two VMs to the same network and let them decide which gets the primary address. On 28 October 2014 10:27, A, Keshava keshav...@hp.commailto:keshav...@hp.com wrote: Hi Alan and Salvatore, Thanks for response and I also agree we need to take small steps. However I have below points to make. It is very important how the Service VM needs will be deployed w.r.t HA. As per current discussion, you are proposing something like below kind of deployment for Carrier Grade HA. Since there is a separate port for Standby-VM also, then the corresponding standby-VM interface address should be globally routable also. Means it may require the Standby Routing protocols to advertise its interface as Next-HOP for prefix it routes. However external world should not be aware of the standby-routing running in the network. [cid:image001.png@01CFF601.E49C6A50] [cid:image002.png@01CFF601.E49C6A50] Instead if we can think of running Standby on same stack with Passive port, ( as shown below) then external world will be unaware of the standing Service Routing running. This may be something very basic requirement from Service-VM (NFV HA perspective) for Routing/MPLS/Packet processing domain. I am brining this issue now itself, because you are proposing to change the basic framework of packer delivering to VM’s. (Of course there may be other mechanism of supporting redundancy, however it will not be as efficient as that of handing at packet level). [cid:image003.png@01CFF601.E49C6A50] Thanks regards, Keshava From: Alan Kavanagh [mailto:alan.kavan...@ericsson.commailto:alan.kavan...@ericsson.com] Sent: Tuesday, October 28, 2014 6:48 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints Hi Salvatore Inline below. From: Salvatore Orlando [mailto:sorla...@nicira.com] Sent: October-28-14 12:37 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints Keshava, I think the thread is not going a bit off its stated topic - which is to discuss the various proposed approaches to vlan trunking. Regarding your last post, I'm not sure I saw either spec implying that at the data plane level every instance attached to a trunk will be implemented as a different network stack. AK-- Agree Also, quoting the principle earlier cited in this thread - make the easy stuff easy and the hard stuff possible - I would say that unless five 9s is a minimum requirement for a NFV application, we might start worrying about it once we have the bare minimum set of tools for allowing a NFV application over a neutron network. AK-- five 9’s is a 100% must requirement for NFV, but lets ensure we don’t mix up what the underlay service needs to guarantee and what openstack needs to do to ensure this type of service. Would agree, we should focus more on having the right configuration sets for onboarding NFV which is what Openstack needs to ensure is exposed then what is used underneath guarantee the 5 9’s is a separate matter. I think Ian has done a good job in explaining that while both approaches considered here address trunking for NFV use cases, they propose alternative implementations which can be leveraged in different way by NFV applications. I do not see now a reason for which we should not allow NFV apps to leverage a trunk network or create port-aware VLANs (or maybe you can even have VLAN aware ports which tap into a trunk network?) AK-- Agree, I think we can hammer this out once and for all in Paris…….this feature has been lingering too long. We may continue discussing the pros and cons of each approach - but to me it's now just a matter of choosing the best solution for exposing them at the API layer. At the control/data plane layer, it seems to me that trunk networks are pretty much straightforward. VLAN aware ports are instead a bit more convoluted, but not excessively complicated in my opinion. AK-- My thinking too Salvatore, lets ensure the right elements are exposed at API Layer, I would also go a little
Re: [openstack-dev] Cross distribution talks on Friday
On 11/01/2014 11:29 AM, Kashyap Chamarthy wrote: On Sat, Nov 01, 2014 at 09:13:21PM +0800, Thomas Goirand wrote: Hi, I was wondering if some distribution OpenStack package maintainers would be interested to have some cross-distribution discussion on Friday, during the contributors sessions. I'll be happy to discuss with Ubuntu people, but not only. I'd like to meet also guys working with RedHat and Gentoo. I'm sure we may have some interesting things to share. OpenStack release management team would also be welcome. If you are interested, please reply to this mail. You might also want to start an etherpad instance with some initial agenda notes and throw the URL here to guage interest. On a related note, a bunch of Fedora/RHEL/CentOS/Scientific Linux packagers are planning[1] to meetup at the summit to discuss RDO project packaging aspects, etc. [1] https://etherpad.openstack.org/p/RDO_Meetup_Summit Getting the whole PBR version issues cleared up would be huge. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC election by the numbers
So, just to round out this thread, the key questions are: * whether a low declining turnout is a real problem I'd like to point out that there 580 'regular' contributors at the moment[1], these are the authors of 95% of the OpenStack code. 506 total number of voters. Thanks Stef, there's great data on that dashboard. I've added the regular contributors per-release to the table (up-thread) showing the percentage of single-patch contributors: Release | Committers | Single-patch | 2-cycle MA | Regular -- Juno| 1556 | 485 (31.2%) | 29.8% | 444 (28.5%) Icehouse| 1273 | 362 (28.4%) | 28.0% | 378 (29.7%) Havana | 1005 | 278 (27.6%) | 28.0% | 293 (29.2%) Grizzly | 630| 179 (28.4%) | 29.2% | 186 (33.8%) Folsom | 401| 120 (29.9%) | 27.9% | 107 (26.7%) Apart from a spike around grizzly, we're not seeing a noticeable dilution of the regular cohort within the total committer population. and, if so: * could this have been driven by a weakness in the voting model, and/or the perception of representative balance in the outcomes I would suggest to explore another possible cause: are the elections advertised enough? Is there enough time for developers to understand also this important part of OpenStack and get involved? Do we use all possible channels to communicate the elections and their importance? Thoughts? Sure, more and better communication is always good. Though I don't know if was anything much different about how this election cycle was advertized compared to others, or whether the typical voter had become harder to reach since previous cycles. Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Cross distribution talks on Friday
On Sat, Nov 01, 2014 at 01:45:24PM -0400, Adam Young wrote: On 11/01/2014 11:29 AM, Kashyap Chamarthy wrote: On Sat, Nov 01, 2014 at 09:13:21PM +0800, Thomas Goirand wrote: Hi, I was wondering if some distribution OpenStack package maintainers would be interested to have some cross-distribution discussion on Friday, during the contributors sessions. I'll be happy to discuss with Ubuntu people, but not only. I'd like to meet also guys working with RedHat and Gentoo. I'm sure we may have some interesting things to share. OpenStack release management team would also be welcome. If you are interested, please reply to this mail. You might also want to start an etherpad instance with some initial agenda notes and throw the URL here to guage interest. On a related note, a bunch of Fedora/RHEL/CentOS/Scientific Linux packagers are planning[1] to meetup at the summit to discuss RDO project packaging aspects, etc. [1] https://etherpad.openstack.org/p/RDO_Meetup_Summit Getting the whole PBR version issues cleared up would be huge. I took the liberty to add the above topic to the etherpad. If you'd like to add more granular details, feel free to edit. -- /kashyap ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [policy] [congress] Protocol for Congress -- Enactor
Summary from IRC chat 10/14/2014 on weekly meeting [1] [2] Topic: Declarative Language for Congress — Enactor/Enforcer Question: Shall we specify a declarative language for communicating policy configured in Congress to enactors / enforcement systems Hypothesis (derived at conclusion of discussion): - Specify declarative protocol and framework for describing policy with extensible attributes/value fields described in a base ontology, with additional affinity ontologies, is what is needed earlier than later, to be able to achieve it as an end-state, before too many Enactors dive into one-offs. - We could achieve that specification once we know the right structure Discussion: - Given the following framework: - Elements: - Congress - The policy description point, a place where: - (a) policy inputs are collected - (b) collected policy inputs are integrated - (c) policy is defined - (d) declares policy intent to enforcing / enacting systems - (e) observes state of environment, noting policy violations - Feeders - provides policy inputs to Congress - Enactors / Enforcers - receives policy declarations from Congress and enacts / enforces the policy according to its capabilities - E.g. Nova for VM placement, Neutron for interface connectivity, FWaaS for access control, etc. What will the protocol be for the Congress — Enactors / Enforcers? thinrichs: we’ve we've been assuming that Congress will leverage whatever the Enactors (policy engines) and Feeders (and more generally datacenter services) that exist are using. For basic datacenter services, we had planned on teaching Congress what their API is and what it does. So there's no new protocol there—we'd just use HTTP or whatever the service expects. For Enactors, there are 2 pieces: (1) what policy does Congress push and (2) what protocol does it use to do that? We don't know the answer to (1) yet. (2) is less important, I think. For (2) we could use opflex, for example, or create a new one. (1) is hard because the Enactors likely have different languages that they understand. I’m not aware of anyone thinking about (2). I’m not thinking about (2) b/c I don't know the answer to (1). The *really* hard thing to understand IMO is how these Enactors should cooperate (in terms of the information they exchange and the functionality they provide). The bits they use to wrap the messages they send while cooperating is a lower-level question. jasonsb glebo: feel the need to clarify (2) glebo: if we come out strongly with a framework spec that identifies a protocol for (2), and make it clear that Congress participants, including several data center Feeders and Enactors, are in consensus, then the other Feeders Enactors will line up, in order to be useful in the modern deployments. Either that, or they will remain isolated from the new environment, or their customers will have to create custom connectors to the new environment. It seems that we have 2 options. (a) Congress learns any language spoken by Feeders and Enactors, or (b) specifies a single protocol for Congress — Enactors policy declarations, including a highly adaptable public registry(ies) for defining the meaning of content blobs in those messages. For (a) Congress would get VERY bloated with an abstraction layer, modules, semantics and state for each different language it needed to speak. And there would be 10s of these languages. For (b), there would be one way to structure messages that were constructed of blobs in (e.g.) some sort of Type/Length/Value (TLV) method, where the Types and Values were specified in some Internet registry. jasonsb: Could we attack this from the opposite direction? E.g. if Congress wanted to provide an operational dashboard to show if things are in compliance, it would be better served by receiving the state and stats from the Enactors in a single protocol. Could a dashboard like this be a carrot to lure the various players into a single protocol for Congress — Enactor? glebo jasonsb: If Congress has to give Enactors precise instructions on what to do, then Congress will bloat, having to have intelligence about each Enactor type, and hold its state and such. If Congress can deliver generalized policy declarations, and the Enactor is responsible for interpreting it, and applying it, and gathering and analyzing the state so that it knows how to react, then the intelligence and state that it is specialized in knowing will live in the Enactor. A smaller Congress is better, and this provides cleaner “layering” of the problem space overall. thinrichs: would love to see a single (2) language, but doesn’t see that as a practical solution in the short term, dubious that anyone will use Congress if it only works when all of the Enactors speak the Congress language. It’s an insertion question. glebo: the key is NOT the bits on the wire,
Re: [openstack-dev] Cross distribution talks on Friday
On 11/01/2014 11:29 PM, Kashyap Chamarthy wrote:
On Sat, Nov 01, 2014 at 09:13:21PM +0800, Thomas Goirand wrote:
Hi,
I was wondering if some distribution OpenStack package maintainers
would be interested to have some cross-distribution discussion on
Friday, during the contributors sessions.
I'll be happy to discuss with Ubuntu people, but not only. I'd like to
meet also guys working with RedHat and Gentoo. I'm sure we may have
some interesting things to share.
OpenStack release management team would also be welcome.
If you are interested, please reply to this mail.
You might also want to start an etherpad instance with some initial
agenda notes and throw the URL here to guage interest.
Here's the etherpad:
https://etherpad.openstack.org/p/cross_distro_talks
On a related note, a bunch of Fedora/RHEL/CentOS/Scientific Linux
packagers are planning[1] to meetup at the summit to discuss RDO project
packaging aspects, etc.
[1] https://etherpad.openstack.org/p/RDO_Meetup_Summit
Well, if you guys are only talking about RPM packaging, as I'm doing
only Debian stuff [1], I'm only mildly interested. If we're going to
talk more about packaging in general, then maybe.
On 11/02/2014 01:45 AM, Adam Young wrote:
Getting the whole PBR version issues cleared up would be huge.
I'm not sure what issue you are talking about, as I believe there's
none. This has been discussed for about a year and a half before we
finally had the OSLO_PACKAGE_VERSION to play with, when this was
designed a few years ago. I'm now very happy about the way PBR does
things, and wouldn't like it to change anything. Currently, what I do in
Debian is (from the debian/rules file included from openstak-pkg-tools):
DEBVERS ?= $(shell dpkg-parsechangelog | sed -n -e 's/^Version: //p')
VERSION ?= $(shell echo '$(DEBVERS)' | sed -e 's/^[[:digit:]]*://' -e
's/[-].*//')
export OSLO_PACKAGE_VERSION=$(VERSION)
You may not be familiar with dpkg-parsechangelog, so let me explain.
Basically, if my debian/changelog has on top 2014.2~rc2, the
debian/rules file will exports 2014.2~rc2 into the OSLO_PACKAGE_VERSION
shell variable before doing python setup.py install, and then PBR is
smart enough to use that.
I am not at all a RedHat packaging specialist, but from the old time
when I did some RPM porting from my Debian packages, I believe that in
your .spec file, this should translate into something like this:
%install
export OSLO_PACKAGE_VERSION=%{version}
%{__python} setup.py install -O1 --skip-build --root %{buildroot}
Then everything should be ok and PBR will become your friend. I hope
this helps and that I'm not writing any RPM packaging mistake! :)
Cheers,
Thomas Goirand (zigo)
[1] Here's the list of packages I maintain in Debian (only for OpenStack):
https://qa.debian.org/developer.php?login=openstack-de...@lists.alioth.debian.org
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [cinder] [barbican] Stable check of openstack/cinder failed
Hi, cinder juno tests are failing after new barbicanclient release - periodic-cinder-python26-juno http://logs.openstack.org/periodic-stable/periodic-cinder-python26-juno/d660c21 : FAILURE in 11m 37s - periodic-cinder-python27-juno http://logs.openstack.org/periodic-stable/periodic-cinder-python27-juno/d9bf4cb : FAILURE in 9m 04s I've filed https://bugs.launchpad.net/cinder/+bug/1388461 AFACT this affects master too. Cheers, Alan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Cross distribution talks on Friday
%install
export OSLO_PACKAGE_VERSION=%{version}
%{__python} setup.py install -O1 --skip-build --root %{buildroot}
Then everything should be ok and PBR will become your friend.
Still not my friend because I don't want a _build_ tool as runtime dependency :)
e.g. you don't ship make(1) to run C programs, do you?
For runtime, only pbr.version part is required but unfortunately
oslo.version was abandoned.
Cheers,
Alan
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
