Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)
On 10/22/2013 04:55 AM, Mark McLoughlin wrote: Talk to the Trove developers and politely ask them whether the copyright notices in their code reflects what they see as the reality. I'm sure it would help them if you pointed out to them some significant chunks of code from the commit history which don't appear to have been written by a HP employee. I did this already. Though if I raised the topic in this list (as opposed to contact the Trove maintainers privately), this was for a broader scope, to make sure it doesn't happen again and again. Simply adding a Rackspace copyright notice to a file or two which has had a significant contribution by someone from Rackspace would be enough to resolve your concerns completely. But how to make sure that there's no *other* copyright holders, and that my debian/copyright is right? Currently, there's no way... Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Common requirements for services' discussion
Hi All, This is a reminder for the next IRC meeting on Tuesday (Oct 22nd) 15.30 UTC (8.30 AM PDT) on the #openstack-meeting-alt channel. The proposed agenda is: * Service insertion and chaining * Service agents * Service VMs - mechanism * Service VMs - policy * Extensible APIs for services and anything else you may want to discuss in this context. Meeting wiki page (has pointer to the first meeting logs): https://wiki.openstack.org/wiki/Meetings/AdvancedServices Thanks, ~Sumit. On Thu, Oct 17, 2013 at 12:02 AM, Sumit Naiksatam sumitnaiksa...@gmail.comwrote: Hi All, We will have the advanced services and the common requirements IRC meeting on Tuesdays 15.30 UTC (8.30 AM PDT) on the #openstack-meeting-alt channel. The meeting time was chosen to accommodate requests by folks in Asia and will hopefully suit most people involved. Please note that this is the alternate meeting channel. The agenda will be a continuation of discussion from the previous meeting with some additional agenda items based on the sessions already proposed for the summit. The current discussion is being captured in this etherpad: https://etherpad.openstack.org/p/NeutronAdvancedServices Hope you can make it and participate. Thanks, ~Sumit. On Mon, Oct 14, 2013 at 8:15 PM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: Thanks all for attending the IRC meeting today for the Neutron advanced services discussion. We have an etherpad for this: https://etherpad.openstack.org/p/NeutronAdvancedServices It was also felt that we need to have more ongoing discussions, so we will have follow up meetings. We will try to propose a more convenient time for everyone involved for a meeting next week. Meanwhile, we can continue to use the mailing list, etherpad, and/or comment on the specific proposals. Thanks, ~Sumit. On Tue, Oct 8, 2013 at 8:30 PM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: Hi All, We had a VPNaaS meeting yesterday and it was felt that we should have a separate meeting to discuss the topics common to all services. So, in preparation for the Icehouse summit, I am proposing an IRC meeting on Oct 14th 22:00 UTC (immediately after the Neutron meeting) to discuss common aspects related to the FWaaS, LBaaS, and VPNaaS. We will begin with service insertion and chaining discussion, and I hope we can collect requirements for other common aspects such as service agents, services instances, etc. as well. Etherpad for service insertion chaining can be found here: https://etherpad.openstack.org/icehouse-neutron-service-insertion-chaining Hope you all can join. Thanks, ~Sumit. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)
On 10/22/2013 05:06 AM, Michael Basnight wrote: so if this is sufficient, ill fix the copyright headers. Please do (and backport that to 2013.2...)! :) Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)
On 10/22/2013 04:48 AM, Mark McLoughlin wrote: On Tue, 2013-10-22 at 01:55 +0800, Thomas Goirand wrote: On 10/21/2013 09:28 PM, Mark McLoughlin wrote: In other words, what exactly is a list of copyright holders good for? At least avoid pain and reject when uploading to the Debian NEW queue... I'm sorry, that is downstream Debian pain. I agree, it is painful, though it is a necessary pain. Debian has always been strict with copyright stuff. This should be seen as a freeness Q/A, so that we make sure everything is 100% free, rather than an annoyance. It shouldn't be inflicted on upstream unless it is generally a useful thing. There's no other ways to do things, unfortunately. How would I make sure a software is free, and released in the correct license, if upstream doesn't declare it properly? There's been some cases on packages I wanted to upload, where there was just: Classifier: License :: OSI Approved :: MIT License in *.egg-info/PKG-INFO, and that's it. If the upstream authors don't fix this by adding a clear LICENSE file (with the correct definition of the MIT License, which is confusing because there's been many of them), then the package couldn't get in. Lucky, upstream authors of that python module fixed that, and the package was re-uploaded and validated by the FTP masters. I'm not saying that this was the case for Trove (the exactitude of the copyright holder list in debian/copyright is less of an issue), though I'm just trying to make you understand that you can't just ignore the issue and say I don't care, that's Debian's problem. This simply doesn't work (unless you would prefer OpenStack package to *not* be in Debian, which I'm sure isn't the case here). Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)
On Tue, 2013-10-22 at 14:09 +0800, Thomas Goirand wrote: On 10/22/2013 04:55 AM, Mark McLoughlin wrote: Talk to the Trove developers and politely ask them whether the copyright notices in their code reflects what they see as the reality. I'm sure it would help them if you pointed out to them some significant chunks of code from the commit history which don't appear to have been written by a HP employee. I did this already. Though if I raised the topic in this list (as opposed to contact the Trove maintainers privately), this was for a broader scope, to make sure it doesn't happen again and again. Simply adding a Rackspace copyright notice to a file or two which has had a significant contribution by someone from Rackspace would be enough to resolve your concerns completely. But how to make sure that there's no *other* copyright holders, and that my debian/copyright is right? Currently, there's no way... I've never seen a project where copyright headers weren't occasionally missing some copyright holders. I suspect Debian has managed just fine with those projects and can manage just fine with OpenStack's copyright headers too. Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)
On 10/22/2013 08:09 AM, Monty Taylor wrote: b) Thomas should put in debian/copyright what is in our headers, and should consider them, as they are in our source tarballs, to be correct c) If Thomas, or anyone else, considers our header attribution to be incorrect, he or she should submit a patch or suggest that someone else submit a patch to the file in question indicating that he or she feels that there is incorrect content in that file ACK. Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Gerrit tools
On 21/10/13 15:41 +0200, Chmouel Boudjnah wrote: On Mon, Oct 21, 2013 at 3:03 PM, Flavio Percoco fla...@redhat.com wrote: Also realize that OpenStack maintains gerritlib - https://github.com/ openstack-infra/gerritlib Which anyone can contribute to (and is the code that every message posted back to gerrit by a bot users). It would actually be nice to enhance gerritlib if there were enough features missing that are in python-gerrit. Yup, that's part of the plan, python-gerrit rewrites a lot of stuff, though. It seems that gerritlib is using SSH commands, isn't that the plans is to have a gerrit with the full REST api enabled in the future without needing to have to spawn ssh commands for every calls? The last time I checked the 'REST' api, I think there were some pieces missing, I could be wrong, though. I'll take another look. Cheers, FF Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)
On 10/22/2013 04:45 AM, Mark McLoughlin wrote: By improve clarity, you mean compile an accurate list of all copyright holders? Why is this useful information? Sure, we could also improve clarity by compiling a list of all the cities in the world where some OpenStack code has been authored ... but *why*? Mark, I haven't asked for things to be 100% accurate. I know that's not possible. I've asked that we make sure headers aren't 90% wrong, which was my gut feeling when writing the trove debian/copyright file and seeing only HP in the headers... The key thing for Debian to understand is that all OpenStack contributors agree to license their code under the terms of the Apache License. I don't see why a list of copyright holders would clarify the licensing situation any further. Mark. Well, I am just willing to write things correctly, and I have been in situations where it wasn't possible easily, and wanted to fix this once and for all, by opening the topic in this list. It is as simple as that. There's no need for the discussion to go *that* far. Nobody is discussing the fact that OpenStack is free software. Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Gerrit tools
On 21/10/13 15:55 +, Joshua Harlow wrote: I am using gerritlib in the curses ui; seems to work nicely. Only 1 thing that I don't like so much is that it silences connection/other errors from what I can tell. See _run() method in https://github.com/openstack-infra/gerritlib/blob/master/gerritlib/gerrit.py I started migrating some of the OpenStack tools to python-gerrit a couple of months ago, I still have that code somewhere in my laptop, I hope. I think that gerritlib API could be improved a lot from python-gerrit, plus query combinations in gerritlib are a bit limited due to how they're expressed there. At least the last time I checked. I'll take some time in the next few weeks to work on that. @Joshua, do you mind taking a look at python-gerrit and provide some feedback or use it? :D Cheers, FF Otherwise pretty easy to use. Sent from my really tiny device... On Oct 21, 2013, at 4:46 AM, Sean Dague s...@dague.net wrote: On 10/21/2013 04:04 AM, Flavio Percoco wrote: On 20/10/13 05:01 +, Joshua Harlow wrote: I created some gerrit tools that I think others might find useful. https://github.com/harlowja/gerrit_view I worked on this Python library for Gerrit[0] a couple of months ago and I've been using it for this gerrit-cli[1] tool. I was wondering if you'd like to migrate your Gerrit queries and make them use python-gerrit instead? I can do that for you. [0] https://github.com/FlaPer87/python-gerrit [1] https://github.com/FlaPer87/gerrit-cli BTW, Big +1 for the curses UI! Also realize that OpenStack maintains gerritlib - https://github.com/openstack-infra/gerritlib Which anyone can contribute to (and is the code that every message posted back to gerrit by a bot users). It would actually be nice to enhance gerritlib if there were enough features missing that are in python-gerrit. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- @flaper87 Flavio Percoco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)
On 10/22/2013 02:12 AM, Jeremy Stanley wrote: On 2013-10-22 01:45:13 +0800 (+0800), Thomas Goirand wrote: [...] The main problem I was facing was that troveclient has a few files stating that HP was the sole copyright holder, when it clearly was not (since I have discussed a bit with some the dev team in Portland, IIRC some of them are from Rackspace...). [...] So, for me, the clean and easy way to fix this problem is to have a simple copyright-holder.txt file, containing a list of company or individuals. It doesn't really mater if some entities forget to write themselves in. After all, that'd be their fault, no? [...] I don't really see the difference here at all. You propose going from... A) copyright claims in headers of files, which contributors might forget to update ...to... B) copyright claims in one file, which contributors might also forget to update I don't understand how adding a file full of duplicate information to each project is going to solve your actual concern. My idea was that in the case of B, it's more easy to fix/patch a single file than lots of them, and also that the existence of the file itself is an invitation for copyright holders to add themselves in, while a copyright header in a source code isn't that explicit. Though I can agree of course, that in both cases, contributors might forget to add themselves in... Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to get VXLAN Endpoint IP without agent
Though we can configure in Nova.conf file, but we have to make sure these tunnel interface ipaddress of every compute node and nova.conf will have the same configuration. But it is still painful to make sure that the ipaddress are configured properly. We want to come up with BP to avoid these manual configuration and as the interfaces are configured through DHCP server, Compute Node tunnel ipaddress will be stored in Neutron and retrieved. If anyone has deployed VXLAN setup with Neutron, Please share your experience on VXLAN “Local-IP” configuration of Compute Node. Regards, Balaji.P From: Ravi Chunduru [mailto:ravi...@gmail.com] Sent: Thursday, October 17, 2013 12:41 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] How to get VXLAN Endpoint IP without agent I guess the intention is to make VXLAN work with out quantum agent. It means you are using an external openflow controller to manage OVS switches. In such a case, there is a need to specifically get the compute node IP from the VM data interface network( and not the management or openstack network interface IP) I think of two solutions 1) There must be a onboarding process for each compute node that can indicate your controller of the compute's local_ip 2) Make sure OVS uses VM data interface network to connect to the controller. I don't prefer 2, as OVS mgmt traffic should not be on VM data network. For solution#1, its a pain to load compute local IP onto openflow controller but it can be automated using puppet etc., (I have verified nova database for compute - but it stores management network interface IP but not from data network- Makes sense as endpoints are on management network) Alternately, we can propose a blueprint to include an option in nova.conf on compute for local_ip as there is a need for consumption using VXLAN based overlay networks. Hope it helps. Thanks, -Ravi. On Tue, Oct 15, 2013 at 3:45 AM, B Veera-B37207 b37...@freescale.commailto:b37...@freescale.com wrote: Hi, Vxlan endpoint ip is configured in ‘/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini’ as ‘local_ip’ While starting openvswitch agent the above local ip is populated in neutron database. Is there any way to get local_ip of compute node without any agent running? Thanks in advance. Regards, Veera. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ravi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] IPv6 DHCP options for dnsmasq
On 21 October 2013 19:51, Sean M. Collins s...@coreitpro.com wrote: The motivation is to help Neutron work with IPv6 - which is a must-have for Comcast. Deutsche Telekom too. We are working on making Neutron interoperate well with a service provider network that's based on IPv6. I look forward to talking about this with people in Hong Kong :) Cheers, -Luke ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] HOT Software configuration proposal
Steve Baker sba...@redhat.com wrote on 21.10.2013 23:02:47:
From: Steve Baker sba...@redhat.com
To: openstack-dev@lists.openstack.org,
Date: 21.10.2013 23:06
Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
On 10/22/2013 08:45 AM, Mike Spreitzer wrote:
Steve Baker sba...@redhat.com wrote on 10/15/2013 06:48:53 PM:
I've just written some proposals to address Heat's HOT software
configuration needs, and I'd like to use this thread to get some
feedback:
https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config
https://wiki.openstack.org/wiki/Heat/Blueprints/native-tools-
bootstrap-config
Please read the proposals and reply to the list with any comments or
suggestions.
Can you confirm whether I have got the big picture right? I think
some of my earlier remarks were mistaken.
You propose to introduce the concept of component and recognize
software configuration as a matter of invoking components --- with a
DAG of data dependencies among the component invocations. While
this is similar to what today's heat engine does for resources, you
do NOT propose that the heat engine will get in the business of
invoking components. Rather: each VM will run a series of component
invocations, and in-VM mechanisms will handle the cross-component
synchronization and data communication.
This is basically correct, except that in-VM mechanisms won't know
much about cross-component synchronization and data communication.
They will just execute whatever components are available to be
executed, and report back values to heat-engine by signalling to
waitconditions.
You propose to add a bit of sugaring for the wait conditionhandle
mechanism, and the heat engine will do the de-sugaring.
Yes, I think improvements can be made on what I proposed, such as
every component signalling when it is complete, and optionally
including a return value in that signal.
Being able to handle completion of single components inside a VM and being
able to pass outputs of those components seems important to me. I think
that should mostly address the requirements for declaring data dependencies
between components that have been discussed before in this thread. If
wait-conditions are the underlying mechanism, fine, as longs as we can hid
it from the template syntax.
For example, something like this should be possible:
components:
comp_a:
type: OS::Heat::SomeCMProvider
properties:
prop1: { get_param: param1 }
prop2: ...
comp_b:
type: OS::Heat::SomeCMProvider
properties:
propA: { get_attr: [ comp_a, some_attr ] }
resources:
serverA:
type: OS::Nova::Server
# ...
components:
- comp_a
serverB:
type: OS::Nova::Server
# ...
components:
- comp_b
I.e. there are two components comp_a and comp_b on two different servers.
comp_a has a data dependency on an attribute of comp_b. If we treat
'properties' as input to components and 'attributes' as output (the way it
is currently done for resources), that should be doable.
BTW, the convention of properties being input and attributes being output,
i.e. that subtle distinction between properties and attributes is not
really intuitive, at least not to me as non-native speaker, because I used
to use both words as synonyms.
Anyway it seems like the current proposal is a starting point with
enhancements on the roadmap, right?
Each component is written in one of a few supported configuration
management (CM) frameworks, and essentially all component
invocations on a given VM invoke components of the same CM framework
(with possible exceptions for one or two really basic ones).
Rather than being limited to a few supported CM tools, I like the
idea of some kind of provider mechanism so that users or heat admins
can add support for new CM tools. This implies that it needs to be
possible to add a component type without requiring custom python
that runs on heat engine.
The heat engine gains the additional responsibility of making sure
that the appropriate CM framework(s) is(are) bootstrapped in each VM.
Maybe. Or it might be up to the user to invoke images that already
have the CM tools installed, or the user can provide a custom
component provider which installs the tool in the way that they want.
As for the cross-component synchronization and data communication
question, at this stage I'm not comfortable with bringing something
like zookeeper into the mix for a general solution for inter-
component communication. If heat engine handles resource
dependencies and zookeeper handles software configuration
dependencies this would result in the state of the stack being split
between two different co-ordination mechanisms.
I think that zookeeper could be an _optional_ backend for this, but using
the current mechanisms in Heat should probably be the primary or default
way of doing this.
We've put quite some effort into heat engine to co-ordinate
[openstack-dev] Merge multiple OVS bridges ?
Hi Currently in Neutron the integration bridge (br-int) and other bridges configured over each physical nic (e.g. br-eth0, br-eth1 etc) are being configured in Compute and Network nodes. What is the logic behind or advantages having 2 OVS bridges in the physical host? Can we have only one bridge for each physical NIC, similar to what linux bridge setup has. And configure/modify the flows such that VLAN conversion is appropriately setup for ingress and egress traffic within the single bridge. Thus also eliminating the veth pairs used to connect the bridges together. Is this a feasible proposal, and can it be worked on? -- Regards Gopi Krishna ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Merge multiple OVS bridges ?
Are the below observations on Havana? From: Gopi Krishna B [mailto:gopi97...@gmail.com] Sent: Tuesday, October 22, 2013 12:52 PM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] Merge multiple OVS bridges ? Hi Currently in Neutron the integration bridge (br-int) and other bridges configured over each physical nic (e.g. br-eth0, br-eth1 etc) are being configured in Compute and Network nodes. What is the logic behind or advantages having 2 OVS bridges in the physical host? Can we have only one bridge for each physical NIC, similar to what linux bridge setup has. And configure/modify the flows such that VLAN conversion is appropriately setup for ingress and egress traffic within the single bridge. Thus also eliminating the veth pairs used to connect the bridges together. Is this a feasible proposal, and can it be worked on? -- Regards Gopi Krishna ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)
On Tue, 2013-10-22 at 14:19 +0800, Thomas Goirand wrote: On 10/22/2013 04:48 AM, Mark McLoughlin wrote: On Tue, 2013-10-22 at 01:55 +0800, Thomas Goirand wrote: On 10/21/2013 09:28 PM, Mark McLoughlin wrote: In other words, what exactly is a list of copyright holders good for? At least avoid pain and reject when uploading to the Debian NEW queue... I'm sorry, that is downstream Debian pain. I agree, it is painful, though it is a necessary pain. Debian has always been strict with copyright stuff. This should be seen as a freeness Q/A, so that we make sure everything is 100% free, rather than an annoyance. A list of copyright holders does nothing to improve the freeness of OpenStack. It shouldn't be inflicted on upstream unless it is generally a useful thing. There's no other ways to do things, unfortunately. How would I make sure a software is free, and released in the correct license, if upstream doesn't declare it properly? There's been some cases on packages I wanted to upload, where there was just: Classifier: License :: OSI Approved :: MIT License in *.egg-info/PKG-INFO, and that's it. If the upstream authors don't fix this by adding a clear LICENSE file (with the correct definition of the MIT License, which is confusing because there's been many of them), then the package couldn't get in. Lucky, upstream authors of that python module fixed that, and the package was re-uploaded and validated by the FTP masters. I fully understand the importance of making it completely clear what the license of a project is and have had to package projects that don't make this clear. Fedora's guidelines on the subject are e.g. https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text I'm not saying that this was the case for Trove (the exactitude of the copyright holder list in debian/copyright is less of an issue), though I'm just trying to make you understand that you can't just ignore the issue and say I don't care, that's Debian's problem. This simply doesn't work (unless you would prefer OpenStack package to *not* be in Debian, which I'm sure isn't the case here). I can say Debian policies that no-one can provide any justification for is Debian's problem. And that's the case with this supposed Debian requires a complete list of copyright holders policy. Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)
On 22 October 2013 20:39, Mark McLoughlin mar...@redhat.com wrote: On Tue, 2013-10-22 at 14:19 +0800, Thomas Goirand wrote: I agree, it is painful, though it is a necessary pain. Debian has always been strict with copyright stuff. This should be seen as a freeness Q/A, so that we make sure everything is 100% free, rather than an annoyance. What Debian asks for is more than anyone else needs, and I've never seen a satisfactory explanation for why Debian requires it. The concordance of licence terms is useful, but the concordance of copyright holders isn't - a) it's usually wrong and b) it's usually wrong and c) unless there is a use case like 'I don't want to use code written by person X', it doesn't serve any purpose ... and it doesn't serve that case, because copyright claimants != authors. It saddens me everytime I put a new package together, because it's such a monumental waste of time. A list of copyright holders does nothing to improve the freeness of OpenStack. Ack. I'm not saying that this was the case for Trove (the exactitude of the copyright holder list in debian/copyright is less of an issue), though I'm just trying to make you understand that you can't just ignore the issue and say I don't care, that's Debian's problem. This simply doesn't work (unless you would prefer OpenStack package to *not* be in Debian, which I'm sure isn't the case here). I can say Debian policies that no-one can provide any justification for is Debian's problem. And that's the case with this supposed Debian requires a complete list of copyright holders policy. I agree - and I say this as a Debian Developer :). The actual policy is: http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile In addition, the copyright file must say where the upstream sources (if any) were obtained, and should name the original authors. The 'copyright information' for the package is not well defined. Currently the FTP masters look for a concordance. I think it would be reasonable to raise a discussion about this - seeking to clarify what needs to be captured - e.g. 'the package has to have a distribution license granted by the copyright holders -or- a statement from the copyright holders that it is in the public domain'. As long as all the claimed copyright holders are claiming the same license, there is nothing more needed for either Debian or it's derivatives to be able to: a) use the package b) redistribute it [per whatever licence] c) filter it if they have license specific policies for some project/environment -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [OpenStack][Swift] how does swift update obj count of container or account?
Hi How does Swift update container object count or account object count after PUT an object? Counting per request or something else? -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack http://www.ustack.com* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] extend Network topology view in horizon
Hi It will be helpful to extend Network topology view in horizon 1. Admin should be able to see the entire/per tenant network topology (we might need a flag to enable/disable it). 2. Supporting ICON for FWaaS/LBaaS/VPNaaS on both admin tenant level, so it will be easy to see the deployments Are there any blueprints to support it ? Thanks Ofer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Reminder: Project release status meeting - 21:00 UTC
Today we'll have the first release meeting of the Icehouse cycle. We'll do a quick post-mortem of the Havana release week, then spend most of the meeting time looking at the Design Summit schedule (discussing, and potentially moving or grouping, cross-topic sessions). Feel free to add extra topics to the agenda: [1] http://wiki.openstack.org/Meetings/ProjectMeeting All program leads should be present (if you can't make it, please name a substitute on [1]). Everyone else is very welcome to attend. The meeting will be held at 21:00 UTC on the #openstack-meeting channel on Freenode IRC. You can look up how this time translates locally at: [2] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20131022T21 See you there, -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Merge multiple OVS bridges ?
Are the below observations on Havana? My observations are w.r.t. Grizzly, but I didnot see any changes in Havana reg. the same. -- Regards Gopi Krishna ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack][Swift] how does swift update obj count of container or account?
Hi Gareth: The process of update object count to container db is synchronized. After the DiskFile finish writing the data to disk, the object-server will make a request to container servers and update the object count. If the request failed, the request will be serialized on the disk, and the object-update will update it to container servers asynchronously. The process of update object count from container db to account db is asynchronized. The container-updater will loop all the container db files in disk and update the object count the account servers. 2013/10/22 Gareth academicgar...@gmail.com Hi How does Swift update container object count or account object count after PUT an object? Counting per request or something else? -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack http://www.ustack.com* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 杨雨 Email: alex890...@gmail.com GitHub: https://github.com/AlexYangYu Weibo: http://www.weibo.com/alexyangyu ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [stackalytics] team meeting minutes October 21
Thanks everyone who have joined Stackalytics meeting. The team reviewed and prioritized blueprints. For the next 0.4 release the following bps were selected: * module-review-backlog-statshttps://blueprints.launchpad.net/stackalytics/+spec/module-review-backlog-stats - reports on review activity for modules * review-punchcardhttps://blueprints.launchpad.net/stackalytics/+spec/review-punchcard - report usual working hours for engineer, similar to https://github.com/stackforge/stackalytics/graphs/punch-card * web-filters-cachinghttps://blueprints.launchpad.net/stackalytics/+spec/web-filters-caching - cache search queries to improve performance The full logs are available below: Minutes: http://eavesdrop.openstack.org/meetings/stackalytics/2013/stackalytics.2013-10-21-15.01.html Minutes (text): http://eavesdrop.openstack.org/meetings/stackalytics/2013/stackalytics.2013-10-21-15.01.txt Log: http://eavesdrop.openstack.org/meetings/stackalytics/2013/stackalytics.2013-10-21-15.01.log.html Sincerely yours, Ilya Shakhat ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Bootstrap 3 update and problems with lesscpy
Hi, I have updates on my work towards getting Horizon updated to Bootstrap 3. I have finished Bootstrap 3 update for Horizon using the old lessc compiler to review the work and I have created two versions: 1. patch that uses original lessc library to be able to review the bootstrap 3 in current Horizon [1] 2. patch that uses Lesscpy but does not compile css properly - for reviewing of the compilation issues [2] (see commit messages for details) I marked these as work in progress because of lesscpy problems but please feel free to have a look and give feedback. So what is remaining is to get lesscpy up to speed with Bootstrap 3. Sascha Peilicke has created a fix to support semicolons in mixin arguments [3] some time agobut it still needs to get into original repository as pull request. The other issues reported are still valid. Buggest issue at the moment seems to be in @media declaration including variable https://github.com/robotis/Lesscpy/issues/18[4]. I have tried to have a look at this but the solution is probably not the best... [5]. I have contacted Sascha regarding this and so far I am waiting for response. Any feedback or help with getting Lesscpy fixed is highly welcome. [1] https://review.openstack.org/#/c/49710/ [2] https://review.openstack.org/#/c/49712/ [3] https://github.com/saschpe/Lesscpy/commits/master [4] https://github.com/robotis/Lesscpy/issues/18 [5] https://github.com/jtomasek/Lesscpy/commits/var_in_media Thanks Jirka On 09/19/2013 01:44 AM, Gabriel Hurley wrote: I'm also strongly against reverting the move to lesscpy. As David said, that change was highly-requested by the downstream distros and other folks packaging Horizon in various ways. Since there's no evidence that lesscpy does not intend to support bootstrap 3 in a reasonable timeframe, reverting the patch in the interim would simply be impatience. The better thing to do as a member of the larger open source community is to contribute your own energy to lesscpy and to help them improve their project in a timely manner. I'm glad to hear that Sasha is already working on that. I'm sure they're happy for the assistance and for having their work utilized by a significant project like Horizon. We'll get to bootstrap 3, but not by undoing work we've already done. Please keep us all updated on the progress upstream, I know I for one look forward to seeing the benefits we can derive from the newer bootstrap code. - Gabriel -Original Message- From: Lyle, David (Cloud Services) [mailto:david.l...@hp.com] Sent: Wednesday, September 18, 2013 8:44 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Horizon] Bootstrap 3 update and problems with lesscpy Right now, master in Horizon is still working toward Havana-rc1. We are still likely more than a week away from master moving to Icehouse-1. As this is the case, reverting a highly desired Havana change to address a blueprint for Icehouse that can be addressed properly upstream in lesscpy does not seem like a good course of action. I understand the amount of work involved in updating Bootstrap, but our goal should be to properly resolve the conflict once we are working on Icehouse. -David On Wednesday, September 18, 2013 6:27 AM Jiri Tomasek [mailto:jtoma...@redhat.com] wrote: Hi all, I've started working on updating Bootstrap to version 3 in Horizon. https://blueprints.launchpad.net/horizon/+spec/bootstrap-update As I have described in blueprint whiteboard, I am experiencing compile problems with the new lesscpy compiler that we started using recently. The compiled css code is incorrect and when running the compilation from terminal, about 200 syntax errors occur. This is related to certain features of Less not being supported by lesscpy. I have created a GIthub issue for lesscpy here: https://github.com/robotis/Lesscpy/issues/22 . Sasha Peilicke has already started working on updating the lesscpy library to support all less features needed to compile Bootstrap 3 properly. Although I think that it will take more than a few weeks before lesscpy is there where we need it. I have part of Bootstrap 3 update ready and as it is quite a large patch I would like to get this in as soon as possible because any rebase to a new Horizon master is quite tedious process. Also there are another blueprints that depend on this update (font-icons and css-breakdown, see dependency tree). So I would like to propose to revert the patch that introduces lesscpy library (a0739c9423 Drop NodeJS dependency in favor of pure-python lesscpy) and use the lessc library for the time being untill lesscpy is capable of compiling Bootstrap 3. I have revert patch ready together with update of lessc library in horizon/bin, which I can make part of Bootstrap-update blueprint and send them right away to gerrit for a review. I have also tested that with this setup the Bootstrap 3 updated Horizon less file compiles properly. When
Re: [openstack-dev] [OpenStack][Swift] how does swift update obj count of container or account?
On Tue, Oct 22, 2013 at 5:33 PM, Alex Yang alex890...@gmail.com wrote: Hi Gareth: The process of update object count to container db is synchronized. After the DiskFile finish writing the data to disk, the object-server will make a request to container servers and update the object count. If the request failed, the request will be serialized on the disk, and the object-update will update it to container servers asynchronously. The process of update object count from container db to account db is asynchronized. The container-updater will loop all the container db files in disk and update the object count the account servers If I start my services like swift-init main start(container-updater will not be launched), the obj-count of account will be 0? for the reason that no container-updater reports data to account. But the truth is not that. The obj-count of account and container is correct in most of simple cases. 2013/10/22 Gareth academicgar...@gmail.com Hi How does Swift update container object count or account object count after PUT an object? Counting per request or something else? -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack http://www.ustack.com* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 杨雨 Email: alex890...@gmail.com GitHub: https://github.com/AlexYangYu Weibo: http://www.weibo.com/alexyangyu ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack http://www.ustack.com* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa] Update: Nova API List for Missing Tempest Tests
Hi, Ivan
Thank you for your information. And I'm sorry for delay reply.
Hi,
I also collect the tests status for nova v3 api manually. You can find the
status of v3 tests in this link:
https://etherpad.openstack.org/p/nova-v3-tests
Because there are some extensions that just extend the attribute of specific
api reponse, or convert some input before specific api
called. There is no url for these extension, but I think we also need check
them. I collect the tempest tests according to the nova api code. check tests
to the action
one by one, list the status file by file.
I have a question. Is there any way to list the nova v3 apis?
If so, I think the checking process of the test implementation can be
automatically.
Best Regards,
-- Masayuki Igawa
Due to these patch https://review.openstack.org/#/c/39609/ and
https://review.openstack.org/#/c/39621/ are still under reviewing. so we
can't add tempest test for nova v3 api. (almost existing tests have been
ported into v3, but these patches depend on the 39609 and 39621). The status
of porting existing tests is also listed in this link. we will add the
missing tests in v2
firstly, when it can be ported into v3, will port it.
Best Regards
Ivan Zhu
On 2013年10月15日 14:25, Masayuki Igawa wrote:
Hi,
First, thank you to an anonymous for updating this list!
- GET /{project_id}/servers/:server_id/diagnostics
And, I have updated: Nova API List for Missing Tempest Tests.
https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWc
The summary of this list:
different count from
Tested or not # of APIs ratio the last time
---
Tested API 124 49.6% +2
Not Tested API 66 26.4% -2
Not Need to Test(*1) 60 24.0% 0
---
Total(*2): 250 100.0% 0
(*1) Because they are deprecated APIs such as nova-network and volume.
(*2) not included v3 APIs
The tempest version is:
commit f55f4e54ceab7c6a4d330f92c8059e46233e3560
Merge: 86ab238 062e30a
Author: Jenkins jenk...@review.openstack.org
mailto:jenk...@review.openstack.org
Date: Mon Oct 14 15:55:59 2013 +
By the way, I saw a design summit proposal related to this topic(*3). I
think
this information should be generated automatically. So I'd like to talk
about
this topic at the summit session.
(*3) Coverage analysis tooling:
http://summit.openstack.org/cfp/details/171
This information would be useful for creating Tempest tests.
Any comments/questions/suggestions are welcome.
Best Regards,
-- Masayuki Igawa
Hi,
# I'm sorry for this resending because my last mail has
unnecessary messages.
I have updated: Nova API List for Missing Tempest Tests.
https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWc
The summary of this list:
different count from
Tested or not# of APIs ratio the last time
---
Tested API 122 48.8% +5
Not Tested API 68 27.2% -5
Not Need to Test(*1) 60 24.0% 0
---
Total(*2): 250 100.0% 0
(*1) Because they are deprecated APIs such as nova-network and
volume.
(*2) not included v3 APIs
I hope this information would be helpful for creating Tempest
tests.
Any comments and questions are welcome.
Best Regards,
-- Masayuki Igawa
Hi, Tempest developers
I have made:
Nova API List for Missing Tempest Tests.
https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWc
This list shows what we should test. That is:
* Nova has 250 APIs(not include v3 APIs).
* 117 APIs are executed(maybe tested).
* 73 APIs are not executed.
* 60 APIs
[openstack-dev] [qa] Update: Nova API List for Missing Tempest Tests
Hi,
Thanks many guys for updating this list!
And, I have updated: Nova API List for Missing Tempest Tests.
https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWc
The summary of this list:
different count from
Tested or not # of APIs ratio the last time
---
Tested API 126 50.4% +2
Not Tested API(*1) 64 25.6% -2
Not Need to Test(*2) 60 24.0% 0
---
Total(*3): 250 100.0% 0
(*1) included 9 Doings
(*2) Because they are deprecated APIs such as nova-network and volume.
(*3) not included v3 APIs
The tempest version is:
-
commit 7ca13ed9daa710cbe1ac348cb903ffada4f8f6d2
Merge: 66ff406 72d7d5b
Author: Jenkins jenk...@review.openstack.org
Date: Mon Oct 21 04:29:49 2013 +
Merge add test for updating server's disk_config test
-
This information would be useful for creating Tempest tests.
Any comments/questions/suggestions are welcome.
And if you notice any mistakes on this list, feel free to correct/update it
please.
Best Regards,
-- Masayuki Igawa
Hi,
First, thank you to an anonymous for updating this list!
- GET /{project_id}/servers/:server_id/diagnostics
And, I have updated: Nova API List for Missing Tempest Tests.
https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWc
The summary of this list:
different count from
Tested or not # of APIs ratio the last time
---
Tested API124 49.6% +2
Not Tested API 66 26.4% -2
Not Need to Test(*1) 60 24.0% 0
---
Total(*2):250 100.0% 0
(*1) Because they are deprecated APIs such as nova-network and volume.
(*2) not included v3 APIs
The tempest version is:
commit f55f4e54ceab7c6a4d330f92c8059e46233e3560
Merge: 86ab238 062e30a
Author: Jenkins jenk...@review.openstack.org
Date: Mon Oct 14 15:55:59 2013 +
By the way, I saw a design summit proposal related to this topic(*3). I think
this information should be generated automatically. So I'd like to talk about
this topic at the summit session.
(*3) Coverage analysis tooling: http://summit.openstack.org/cfp/details/171
This information would be useful for creating Tempest tests.
Any comments/questions/suggestions are welcome.
Best Regards,
-- Masayuki Igawa
Hi,
# I'm sorry for this resending because my last mail has unnecessary
messages.
I have updated: Nova API List for Missing Tempest Tests.
https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWc
The summary of this list:
different count from
Tested or not# of APIs ratio the last time
---
Tested API 122 48.8% +5
Not Tested API 68 27.2% -5
Not Need to Test(*1) 60 24.0% 0
---
Total(*2): 250 100.0% 0
(*1) Because they are deprecated APIs such as nova-network and volume.
(*2) not included v3 APIs
I hope this information would be helpful for creating Tempest tests.
Any comments and questions are welcome.
Best Regards,
-- Masayuki Igawa
Hi, Tempest developers
I have made:
Nova API List for Missing Tempest Tests.
https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWc
This list shows what we should test. That is:
* Nova has 250 APIs(not include v3 APIs).
* 117 APIs are executed(maybe tested).
* 73 APIs are not executed.
* 60 APIs are not executed. But they maybe not need to test.
- Because they are deprecated APIs such as nova-network and volume.
So I think we need more tempest test cases.
If this idea is acceptable, can you put your name to 'assignee' at your
favorites,
and implement tempest tests.
Any comments are welcome.
Additional information:
I made this API list with modification of nova's code that based on
https://review.openstack.org/#/c/25882/ (Abandoned).
Best Regards,
-- Masayuki Igawa
smime.p7s
Description: S/MIME cryptographic signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Sheepdog Announcement] Erasure coding is fully functional with Sheepdog now
Hello all, Apologies if this mail sounds annoying to you. Sheepdog is a distributed object storage system for QEMU VM and RESTful services (in progress). Openstack users can make use of Sheepdog as Cinder and Glance storage as of now and Swift compatitable API is working in progress. Yuan will introduce sheepdog in the openstack Hong Kong summit and slides are already available at http://www.slideshare.net/multics/sheepdog-yet-another-all-inone-storage-for-openstack-27402520 You can see more info about this talk at http://openstacksummitnovember2013.sched.org/event/706dc3952a8917aa74998e047d015e6a#.UmZnNYYW31E Erasure coding is now seamlessly functional with all other features such as snapshot/clone/cluster-wide snapshot/multi-disk/auto-healing e.c with following characteristics: 1 Data is erasure coded automatically while being written to sheepdog storage, no extra operations. 2 Support random read/write, in-place-update, misaligned read/write 3 Support to run any type VM images or attach as a vdisk of a VM 4 User-defined coding scheme on a VDI basis 5 Better read/write performance compared to fully replication scheme 6 A single cluster can both support replicated VDI or erasure-coded VDI You can get more info at https://github.com/sheepdog/sheepdog/wiki for a general wiki https://github.com/sheepdog/sheepdog/wiki/Erasure-Code-Support for erasure coding Anyone who is interested can give it a try if you are confortable with command line: $ git clone https://github.com/sheepdog/sheepdog.git For a 10 minutes quick start with a single machine, you can try: (Assume you are debian based system) # Compile from the source $ sudo apt-get install liburcu-dev $ git clone git://github.com/sheepdog/sheepdog.git $ cd sheepdog $ ./autogen.sh; ./configure --disable-corosync $ make; sudo make install # Create a 6 node cluster with local driver $ for i in `seq 0 5`; do sheep /tmp/store$i -n -c local -z $i -p 700$i;done $ dog cluster format # Create a replicated thin-provisioned 20G volume with 3 copies $ dog vdi create -c 3 replica 20G $ dog vdi list # show vdi list $ dog node info # show node information $ dog cluster info # show cluster infomation # Create a erasure-coded (4 data strips and 2 parity strips) 20G volume $ dog vdi create -c 4:2 erasure 20G # Now you should have 2 vdi created $ dog vdi list # You can install OS on these volumes with upstream QEMU $ qemu-system-x86_64 -m 1024 --enable-kvm \ -drive file=sheepdog:erasure,if=virtio -cdrom path_to_your_iso # or attach the volumes with existant VM $ qemu-system-x86_64 -m 1024 --enable-kvm \ -drive file=your_image,if=virtio -drive file=sheepdog:erasure,if=virtio # Take a live disk-only snapshot of running VM $ dog vdi snapshot -s tag erasure # Mount the volume(vdi) to local storage file system $ sheepfs dir $ echo erasure dir/vdi/mount # then you can do whatever with the mounted file at dir/vdi/volume/erasure Have fun And feedbacks are always welcome. Thanks Yuan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] openstack-dev][nova][neturon] NoopFirewallDriver lead nova boot/show/list failure.
Hi Eric, Instead of the new patch you may consider reverting an old one: https://review.openstack.org/#/c/23160/ https://bugs.launchpad.net/neutron/+bug/1124117 IMHO there's some confusion in bug #1124117 and in the patch in review #23160 about how a noop driver is expected to work. I believe a noop driver should look like it is present (in the list of available extensions), but does nothing. The patch in review #23160 believes an other way and makes the noop driver look like as if it wasn't even present. Which may lead to your current bug. Best regards, Bence Romsics On Sat, Oct 19, 2013 at 10:09 AM, Chang Bo Guo guoc...@cn.ibm.com wrote: Hi ALL, There is bug https://bugs.launchpad.net/python-neutronclient/+bug/1232965. When set firewall_driver = neutron.agent.firewall.NoopFirewallDriver in /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini , Nova operations (list/show/boot) will fail. due to Nuetron client raises NotFound security_group exception. I submit a patch for Nova to fix nova show/list failure. See https://review.openstack.org/#/c/52597/ My question is , which side (Neutron, NeutronClient ,Nova) should fix this , what's the best solution , current I just catch the exception and return empty list of security_group . Any thoughts ? Best Regards --- Eric Guo 郭长波 Cloud Solutions and Openstack Development China System Technology Laboratories (CSTL), IBM Tel:86-10-82452019 Internet Mail: guoc...@cn.ibm.com ___ 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] Merge multiple OVS bridges ?
On Oct 22, 2013, at 2:21 AM, Gopi Krishna B gopi97...@gmail.com wrote: Hi Currently in Neutron the integration bridge (br-int) and other bridges configured over each physical nic (e.g. br-eth0, br-eth1 etc) are being configured in Compute and Network nodes. What is the logic behind or advantages having 2 OVS bridges in the physical host? Can we have only one bridge for each physical NIC, similar to what linux bridge setup has. And configure/modify the flows such that VLAN conversion is appropriately setup for ingress and egress traffic within the single bridge. Thus also eliminating the veth pairs used to connect the bridges together. Is this a feasible proposal, and can it be worked on? Sure, please file a blueprint and submit a patch for this, I would review this for sure! :) There are optimizations underway around this area. For example, we're looking at possibly collapsing the individual Linuxbridge and OVS agents into a single agent. In the context of ML2, this makes sense. I've thought a bit about collapsing the bridges from two to one and this is something which seems quite doable frankly. Thanks, Kyle -- Regards Gopi Krishna ___ 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] Error while executing 'git review'
Hi All, I worked on bug # 1176683 and fixed it. Commit is successful. sridhar@ubuntu:~/repo/neutron$ git status # On branch bug_id_1176683nothing to commit (working directory clean)sridhar@ubuntu:~/repo/neutron$ But getting following error while posting for review. sridhar@ubuntu:~/repo/neutron$ git reviewremote: Resolving deltas: 100% (4/4)remote: Processing changes: refs: 1, doneTo ssh://saggezz...@review.openstack.org:29418/openstack/neutron.git ! [remote rejected] HEAD - refs/for/master/bug/1176683 (change 52949 closed)error: failed to push some refs to 'ssh://saggezz...@review.openstack.org:29418/openstack/neutron.git'sridhar@ubuntu:~/repo/neutron$ Could anyone help in resolving this issue ? RegardsSridhar___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] HOT Software configuration proposal
On 22/10/13 09:15, Thomas Spatzier wrote: BTW, the convention of properties being input and attributes being output, i.e. that subtle distinction between properties and attributes is not really intuitive, at least not to me as non-native speaker, because I used to use both words as synonyms. As a native speaker, I can confidently state that it's not intuitive to anyone ;) We unfortunately inherited these names from the Properties section and the Fn::GetAtt function in cfn templates. It's even worse than that, because there's a whole category of... uh... things (DependsOn, DeletionPolicy, c.) that don't even have a name - I always have to resist the urge to call them 'attributes' too. - ZB ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] openstack-dev][nova][neturon] NoopFirewallDriver lead nova boot/show/list failure.
Hi, Thank you for moving it to the mailing list. Nova operations (list/show/boot) will fail. due to Nuetron client raises NotFound security_group exception. I submit a patch for Nova to fix nova show/list failure. See https://review.openstack.org/#/c/52597/ Regarding on this point, security group extension is not supported by some Neutron plugins and I think it is some kind of configuration issues. IMO it is better to keep raising an exception (or at least ERROR level log should be recorded) to find this kind of configuration mismatch. If neutron plugin does not support security group extension, security_group_driver in nova.conf should be nova. IMO, similarly if NoopFirewallDriver is used in neutron agent, Neutron security group does nothing and security_group_driver in nova.conf should be nova to make security group work. An alternative is to change nova security group driver to check if security group extension is enabled in Neutron and if it is not supported not to issue API calls to Neutron related to security group. I think both approaches should work even after nova-network is removed (in the future). IMHO there's some confusion in bug #1124117 and in the patch in review #23160 about how a noop driver is expected to work. I believe a noop driver should look like it is present (in the list of available extensions), but does nothing. The patch in review #23160 believes an other way and makes the noop driver look like as if it wasn't even present. Which may lead to your current bug. When firewall_driver is set to NoopFirwallDriver in Neutron agent, uses can create security group and its rules, but no packet filtering is enforced. If neutron security group is enabled, users should expect packet filtering is enabled I think this behavior is confusing from Neutron API perspective, and if no packet filtering is enforced, we cannot say security group feature is provided. This is the background of the change. On the other hand, we can consider NoopFirewallDriver means just packet filtering is disabled. I understand there is a need to disable security group completely for debugging or some cases. (Nova security group implementation takes this approach, but it is not a reason.) When we discuss this topic, we need to consider it from the two views: API perspective and agent behavior perspective. When I wrote the patch, my vote was to keep consistent between API level and its actual behavior, but I am open to the community consensus. Which is better or is there any alternative? Thanks, Akihiro On Tue, Oct 22, 2013 at 9:29 PM, Bence Romsics ruba...@gmail.com wrote: Hi Eric, Instead of the new patch you may consider reverting an old one: https://review.openstack.org/#/c/23160/ https://bugs.launchpad.net/neutron/+bug/1124117 IMHO there's some confusion in bug #1124117 and in the patch in review #23160 about how a noop driver is expected to work. I believe a noop driver should look like it is present (in the list of available extensions), but does nothing. The patch in review #23160 believes an other way and makes the noop driver look like as if it wasn't even present. Which may lead to your current bug. Best regards, Bence Romsics On Sat, Oct 19, 2013 at 10:09 AM, Chang Bo Guo guoc...@cn.ibm.com wrote: Hi ALL, There is bug https://bugs.launchpad.net/python-neutronclient/+bug/1232965. When set firewall_driver = neutron.agent.firewall.NoopFirewallDriver in /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini , Nova operations (list/show/boot) will fail. due to Nuetron client raises NotFound security_group exception. I submit a patch for Nova to fix nova show/list failure. See https://review.openstack.org/#/c/52597/ My question is , which side (Neutron, NeutronClient ,Nova) should fix this , what's the best solution , current I just catch the exception and return empty list of security_group . Any thoughts ? Best Regards --- Eric Guo 郭长波 Cloud Solutions and Openstack Development China System Technology Laboratories (CSTL), IBM Tel:86-10-82452019 Internet Mail: guoc...@cn.ibm.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] HOT Software configuration proposal
Zane Bitter zbit...@redhat.com wrote on 10/22/2013 09:24:28 AM: On 22/10/13 09:15, Thomas Spatzier wrote: BTW, the convention of properties being input and attributes being output, i.e. that subtle distinction between properties and attributes is not really intuitive, at least not to me as non-native speaker, because I used to use both words as synonyms. As a native speaker, I can confidently state that it's not intuitive to anyone ;) We unfortunately inherited these names from the Properties section and the Fn::GetAtt function in cfn templates. It's even worse than that, because there's a whole category of... uh... things (DependsOn, DeletionPolicy, c.) that don't even have a name - I always have to resist the urge to call them 'attributes' too. At least for the components construct being proposed (by Steve Baker), shall we adopt a more explicit convention and require component definitions to explicitly name their inputs and outputs? Thanks, LN___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] [qa] Ceilometer ERRORS in normal runs
Hi, On Mon, Oct 21, 2013 at 02:27:44PM +, Neal, Phil wrote: https://blueprints.launchpad.net/tempest/+spec/basic-tempest-integration-for-ceilometer Some works have been done behind an other blueprint: https://blueprints.launchpad.net/tempest/+spec/add-basic-ceilometer-tests Most of this code have been written since a while, and need to be rebased. And some other have showed bugs in ceilometer. Bugs discovered with gate already have fixed in gerrit, and should be merged soon. -Original Message- From: Sean Dague [mailto:s...@dague.net] Sent: Sunday, October 20, 2013 7:39 AM To: OpenStack Development Mailing List Ceilometer is currently one of the largest offenders in dumping ERRORs in the gate - http://logs.openstack.org/68/52768/1/check/check-tempest-devstack-vm- full/76f83a4/console.html#_2013-10-19_14_51_51_271 (that item isn't in our whitelist yet, so you'll see a lot of it at the end of every run) and http://logs.openstack.org/68/52768/1/check/check-tempest-devstack-vm- full/76f83a4/logs/screen-ceilometer-collector.txt.gz?level=TRACE for full details I have planned to take a look on this, this week. Regards, -- Mehdi Abaakouk mail: sil...@sileht.net irc: sileht signature.asc Description: Digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack][Swift] how does swift update obj count of container or account?
I think you can try it again with a clean environment. 2013/10/22 Gareth academicgar...@gmail.com On Tue, Oct 22, 2013 at 5:33 PM, Alex Yang alex890...@gmail.com wrote: Hi Gareth: The process of update object count to container db is synchronized. After the DiskFile finish writing the data to disk, the object-server will make a request to container servers and update the object count. If the request failed, the request will be serialized on the disk, and the object-update will update it to container servers asynchronously. The process of update object count from container db to account db is asynchronized. The container-updater will loop all the container db files in disk and update the object count the account servers If I start my services like swift-init main start(container-updater will not be launched), the obj-count of account will be 0? for the reason that no container-updater reports data to account. But the truth is not that. The obj-count of account and container is correct in most of simple cases. 2013/10/22 Gareth academicgar...@gmail.com Hi How does Swift update container object count or account object count after PUT an object? Counting per request or something else? -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack http://www.ustack.com* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 杨雨 Email: alex890...@gmail.com GitHub: https://github.com/AlexYangYu Weibo: http://www.weibo.com/alexyangyu ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack http://www.ustack.com* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 杨雨 Email: alex890...@gmail.com GitHub: https://github.com/AlexYangYu Weibo: http://www.weibo.com/alexyangyu ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] [qa] Ceilometer ERRORS in normal runs
On 10/21/2013 10:27 AM, Neal, Phil wrote: Sean, we currently have a BP out there to investigate basic tempest integration and I think this might fall under the same umbrella. Unfortunately I've not been able to free up my development time for it, but I've assigned it out to someone who can take a look and report back. https://blueprints.launchpad.net/tempest/+spec/basic-tempest-integration-for-ceilometer This is kind of worse than tempest integration issues. As far as I can tell ceilometer via devstack is basically non functional at all. And sort of worse than non functional, it's spewing errors, a lot. This really ought to be a top ceilometer item to address, otherwise we should probably turn off celiometer in devstack by default, because it's really not working at the moment. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Fwd: Secure live VM migration in cloud (openstack)
Hi, I need some assistance. i am very confused in one thing of Openstack. How it manages VM's . i mean to say where i can find all files related to single VM . i have Vbox on my system and in the VM main folder i have 3 files and 1 folder. I have attached snapshot of it. How can i see those files for VM in Openstack. I know it uses XEN/KVM hypervisor but where it store the VM all related files. I tried to find it on Openstack but no success yet. I would be very thankful to you Regards Naveed On Wed, Oct 2, 2013 at 12:02 AM, Joshua Harlow harlo...@yahoo-inc.comwrote: Sure, I'd like to hear about it :) From: Naveed Ahmad 12msccsnah...@seecs.edu.pk Date: Tuesday, October 1, 2013 11:22 AM To: Joshua Harlow harlo...@yahoo-inc.com Subject: Re: [openstack-dev] Secure live VM migration in cloud (openstack) Hi Respected Sir, Hopefully you will be fine. previously i discussed with you about my thesis. can i share with you flow of secure live vm migration process w r t cloud . i almost completed the design that i will implement in libvirt/openstack. Regards On Tue, Aug 27, 2013 at 11:12 AM, Naveed Ahmad 12msccsnah...@seecs.edu.pk wrote: Sir i have seen openstack code yet and you are right , it is possible with nova. i will update you soon about my plan. Thanks for sharing useful links and thanks for nice discussion. Regards On Tue, Aug 27, 2013 at 9:29 AM, Joshua Harlow harlo...@yahoo-inc.comwrote: Cool, so are u thinking about doing most of this at the openstack code level then or at the libvirt level?? I could see it being possible to do this in nova itself, or at a lower level in libvirt. U might be interested in a wiki I made a while ago @ https://wiki.openstack.org/wiki/LiveMigrationWorkflows It might not be fully accurate, but u can likely determine the places u would need to change from that. Also https://blueprints.launchpad.net/nova/+spec/unified-migrations might be interesting to u. From: Naveed Ahmad 12msccsnah...@seecs.edu.pk Date: Monday, August 26, 2013 9:04 PM To: Joshua Harlow harlo...@yahoo-inc.com Subject: Re: [openstack-dev] Secure live VM migration in cloud (openstack) Respected Joshua Harlow, no i did not talk with libvirt team. but i have seen feature list of libvirt only and documentation of openstack. Regards On Tue, Aug 27, 2013 at 2:58 AM, Joshua Harlow harlo...@yahoo-inc.comwrote: Hi, Those ideas sounds pretty good to me. Although I'm not an expert in the security area, have u talked with the libvirt folks. I wonder if they have any of this planned? From: Naveed Ahmad 12msccsnah...@seecs.edu.pk Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: Monday, August 26, 2013 11:10 AM To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Secure live VM migration in cloud (openstack) Respected Joshua Harlow, Thanks for reply, Based on literature survey i found that following techniques are used for secure live migration of vm. 1. RSA with SSL protocol for authentication and encryption. As you mentioned earlier same problem is in RSA based authentication. we have to add public keys of all other hypervisors. In Blackhat 2013, security research found vulnerability in SSL so it can be breakable in very short time. please check http://arstechnica.com/security/2013/08/gone-in-30-seconds-new-attack-plucks-secrets-from-https-protected-pages/ 2. SSH is used for secure tunnel before live vm migration. Authentication is not discussed, only secure tunnel is used to achieve confidentiality. 3. Openstack uses libvirtd with kvm to provide secure vm migration between src and dst machine. SSL is used for encrypted channel and SASL is used for authentication. so i am interested to implement authentication level's in live vm migration. 1.no authentication 2. Certificate base 3.smart card based authentication and similarly ssl provide secure channel but after that seaprate VLAN is used for vm migration traffic. if we use ipsec then we can achieve same goal on network layer to hide all communication of vm migration. Regards Naveed On Mon, Aug 26, 2013 at 2:44 AM, Joshua Harlow harlo...@yahoo-inc.comwrote: Arg, hit send to quick. *likely these problems would require some managed migration thing that would temporarily open the network access, issue temporary auth keys and the initiate the migration between the 2 hypervisors. Is this in your scope, to make this thing?? Sent from my really tiny device... On Aug 25, 2013, at 2:42 PM, Joshua Harlow harlo...@yahoo-inc.com wrote: Hi, I think it's a good idea, can u describe more what would be different, would there be a new auth and live migration mechanism? I think one of the problems at least yahoo has is that live migration requires all ssh keys to be on
Re: [openstack-dev] CLA (was: Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects)
(Disclaimers: I am not a lawyer, which likely explains my lack of interest in perversely pointless paperwork. Also, these opinions are my own and do not necessarily reflect those of my employer. Setting MFT to legal-discuss as a more appropriate forum for these sorts of discussions.) On 2013-10-22 15:11:25 +0200 (+0200), Zane Bitter wrote: [...] Can't we just write Copyright OpenStack Contributors? (Where 'contributors' means individuals or organisations who have signed the CLA.) [...] Actually, technically not. There are other avenues through which patches come (posts on mailing lists, attachments to bugs) and I know that from time to time contributors git-am other authors' bug fixes without first asking them to go agree to an OpenStack CLA and prove that they have done so. The actual copyright belongs with the author (or their employer under a work-for-hire agreement), not the contributor who uploaded that work--and they aren't necessarily always the same people. Gerrit ensures that only OpenStack Contributors (those that have signed the CLA) can contribute to OpenStack [...] To echo Monty's sentiments earlier in the thread, and also as the person who spear-headed the current CLA enforcement configuration in our project's Gerrit instance, I don't see how our CLAs add anything of value. It's patronizing, almost insulting, to ask developers to pinky-swear that they're authorized to license the code they contribute under the license included with the code they contribute. At best it may provide a warm fuzzy feeling for companies who are unfamiliar with contributing to free software projects, since free software licenses are all about waiving your rights rather than enforcing them and that might sound scary to the uninitiated... but better efforts toward educating them about free software may prove more productive than relying on a legal security blanket. Also as mentioned above, Gerrit does not enforce that the copyright holder has agreed to this, it only enforces that the person *uploading* the code into Gerrit has agreed to it... and section 7 of the ICLA has some interesting things to say about submitting third-party contributions, which looks to me like a permitted loophole for getting ASL code into the project without the author directly agreeing to a CLA at all. 7. Should You wish to submit work that is not Your original creation, You may submit it to the Project Manager separately from any Contribution, identifying the complete details of its source and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work as Submitted on behalf of a third-party: [named here]. I wonder if the current de facto practice of allowing git's author header to reflect the identity of the third-party counts as a conspicuous mark for the purposes of ICLA section 7? And whether submitting it to Gerrit where it can be openly inspected by the entire project counts as a submission to the Project Manager (the OpenStack Foundation) as well? At any rate, it seems that the agreement boils down to copyright holders promise that they're contributing code under this license, or that they're submitting someone else's work who probably is okay with it. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] HOT Software configuration proposal
Zane Bitter zbit...@redhat.com wrote on 22.10.2013 15:24:28:
From: Zane Bitter zbit...@redhat.com
To: openstack-dev@lists.openstack.org,
Date: 22.10.2013 15:27
Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
On 22/10/13 09:15, Thomas Spatzier wrote:
BTW, the convention of properties being input and attributes being
output,
i.e. that subtle distinction between properties and attributes is not
really intuitive, at least not to me as non-native speaker, because I
used
to use both words as synonyms.
As a native speaker, I can confidently state that it's not intuitive to
anyone ;)
Phew, good to read that ;-)
We unfortunately inherited these names from the Properties section and
the Fn::GetAtt function in cfn templates. It's even worse than that,
because there's a whole category of... uh... things (DependsOn,
DeletionPolicy, c.) that don't even have a name - I always have to
resist the urge to call them 'attributes' too.
So is this something we should try to get straight in HOT while we still
have the flexibility?
Regarding properties/attributes for example, to me I would call both just
properties of a resource or component, and then I can write them or read
them like:
components:
my_component:
type: ...
properties:
my_prop: { get_property: [ other_component, other_component_prop ] }
other_component:
# ...
I.e. you write property 'my_prop' of 'my_component' in its properties
section, and you read property 'other_component_prop' of 'other_component'
using the get_property function.
... we can also call them attributes, but use one name, not two different
names for the same thing.
- ZB
___
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] [TripleO] Tuskar UI L2-Group Creation and Nodes Registering wireframes
Hi everybody, you can find updated version of workflows for Creating L2-Group and Adding New Nodes at new discussion tool for UX: http://ask-openstackux.rhcloud.com/question/7/tuskar-ui-l2-groups-and-nodes/ For any feedback, please follow the conversation there Thanks -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] [qa] Ceilometer ERRORS in normal runs
On 10/22/2013 10:19 AM, Sean Dague wrote: On 10/21/2013 10:27 AM, Neal, Phil wrote: Sean, we currently have a BP out there to investigate basic tempest integration and I think this might fall under the same umbrella. Unfortunately I've not been able to free up my development time for it, but I've assigned it out to someone who can take a look and report back. https://blueprints.launchpad.net/tempest/+spec/basic-tempest-integration-for-ceilometer This is kind of worse than tempest integration issues. As far as I can tell ceilometer via devstack is basically non functional at all. And sort of worse than non functional, it's spewing errors, a lot. This really ought to be a top ceilometer item to address, otherwise we should probably turn off celiometer in devstack by default, because it's really not working at the moment. -Sean Here are the two errors showing up persistently that are not whitelisted. Such log errors are now being shown in the console log right after the tempest tests finish. https://bugs.launchpad.net/ceilometer/+bug/1243251 2013-10-21 21:11:00.229 | 2013-10-21 21:05:20.046 5624 ERROR ceilometer.collector.dispatcher.database [-] Failed to record metering data: QueuePool limit of size 5 overflow 10 reached, connection timed out, timeout 30 https://bugs.launchpad.net/ceilometer/+bug/1243249 2013-10-21 20:22:27.600 | Log File: ceilometer-alarm-evaluator 2013-10-21 20:22:27.600 | 2013-10-21 20:14:33.038 22760 ERROR ceilometer.alarm.service [-] alarm evaluation cycle failed See also https://bugs.launchpad.net/ceilometer/+bug/1237671 -David ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Hyper-V Meeting Agenda
Hi everyone, In today's meeting we will discuss the following topics. * Havana Release * Installer Update * Puppet updates Peter J. Pouliot, CISSP Senior SDET, OpenStack Microsoft New England Research Development Center One Memorial Drive,Cambridge, MA 02142 ppoul...@microsoft.commailto:ppoul...@microsoft.com | Tel: +1(857) 453 6436 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] [qa] Ceilometer ERRORS in normal runs
Hi guys, I can share my experience with devstack+ceilometer. There is certainly a problem with MongoDB, because Ceilometer requires more fresh Mongo than devstack provides. But I didn't experienced problems with SQL. And just a quick question about testing: are there any plans to test Ceilometer with different db-backends in devstack? Or do you suggest that it is not devstack's responsibility? Thanks, Nadya On Tue, Oct 22, 2013 at 6:55 PM, David Kranz dkr...@redhat.com wrote: On 10/22/2013 10:19 AM, Sean Dague wrote: On 10/21/2013 10:27 AM, Neal, Phil wrote: Sean, we currently have a BP out there to investigate basic tempest integration and I think this might fall under the same umbrella. Unfortunately I've not been able to free up my development time for it, but I've assigned it out to someone who can take a look and report back. https://blueprints.launchpad.**net/tempest/+spec/basic-** tempest-integration-for-**ceilometerhttps://blueprints.launchpad.net/tempest/+spec/basic-tempest-integration-for-ceilometer This is kind of worse than tempest integration issues. As far as I can tell ceilometer via devstack is basically non functional at all. And sort of worse than non functional, it's spewing errors, a lot. This really ought to be a top ceilometer item to address, otherwise we should probably turn off celiometer in devstack by default, because it's really not working at the moment. -Sean Here are the two errors showing up persistently that are not whitelisted. Such log errors are now being shown in the console log right after the tempest tests finish. https://bugs.launchpad.net/**ceilometer/+bug/1243251https://bugs.launchpad.net/ceilometer/+bug/1243251 2013-10-21 21:11:00.229 | 2013-10-21 21:05:20.046 5624 ERROR ceilometer.collector.**dispatcher.database [-] Failed to record metering data: QueuePool limit of size 5 overflow 10 reached, connection timed out, timeout 30 https://bugs.launchpad.net/**ceilometer/+bug/1243249https://bugs.launchpad.net/ceilometer/+bug/1243249 2013-10-21 20:22:27.600 | Log File: ceilometer-alarm-evaluator 2013-10-21 20:22:27.600 | 2013-10-21 20:14:33.038 22760 ERROR ceilometer.alarm.service [-] alarm evaluation cycle failed See also https://bugs.launchpad.net/**ceilometer/+bug/1237671https://bugs.launchpad.net/ceilometer/+bug/1237671 -David __**_ OpenStack-dev mailing list OpenStack-dev@lists.openstack.**org OpenStack-dev@lists.openstack.org http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-devhttp://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] [TripleO] Tuskar UI - Resource Class Creation Wireframes - updated
We moved the whole conversation to new OpenStack UX discussion tool, feel free to follow the thread there: http://ask-openstackux.rhcloud.com/question/5/tuskar-ui-resource-class-creation/ On 2013/21/10 20:59, Liz Blanchard wrote: Hi Jarda, Below you will find my comments and questions on the latest version of the Resource Class Creation wireframes. Please let me know if you have any questions. Thanks, Liz On Oct 16, 2013, at 12:31 PM, Jaromir Coufal jcou...@redhat.com mailto:jcou...@redhat.com wrote: Hey folks, I am sending an updated version of wireframes for Resource Class Creation. Thanks everybody for your feedback, I tried to cover most of your concerns and I am sending updated version for your reviews. If you have any concerns, I am happy to discuss it with you. http://people.redhat.com/~jcoufal/openstack/tuskar/2013-10-16_tuskar_resource_class_creation_wireframes.pdf 1) Will the user be able to click on any of the wizard steps in the menu at the top? 2) There shouldn't be a Back button on the first step of the wizard. The user will never have an opportunity to go back from here. 3) First class should be selected by default. Especially if the field that changes below is just the description. 4) Rather than labeling the class description with the class name, it should be Class Description:. 5) The Assist checkbox labeling is confusing. Perhaps Assist with proper halving of resources would be better? 6) If the user unselects the Assist checkbox, it would be great if that section could collapse to save space. Alternatively, it would reappear if the user selects the checkbox again. 7) How come the user can't click the back button from the 2nd page? It looks greyed out like the Hardware Profile button. 8) I think we need a clearer design for when a table is empty. Maybe even a small message within the table along the lines of There are currently no items. 9) Rather than Yes and No in the confirmation dialog, I think it would make it more clear to the user if the action they were taking is used. For example Start Over or Enable Assistant would be more descriptive. 10) Is the Node Profile name going to be reflected in the tab name above? If so, it might be nice to fill in the field for Profile Name to be Node Profile 1 by default. Then it could change as the user changes it in the field. 11) It would be better to name the Add Row link more specifically to the action. Probably Add Requirement in this case. 12) Is the Associated Images field supposed to be a drop down? Or should there be a Browse button? I'm just wondering why it has the helper text Choose an image. 13) Would the image have an extension associated with it? If so, it might be good to show different examples here (Ex. QCOW2, ISO, IMG) 14) Are you sure we should select Nodes to assign to this resource class by default? It would be nice to ask some sample users this type of thing. 15) I think we can combine the label of 4 Matching Available Nodes and the select action. This way, it would be clear that the user would be selecting the 4 matching nodes... 16) The filter/search should be aligned closer to the table that it is filtering. 17) Where does the L2-default_group name come from in this list? 18) The filter description should probably be shortened to read Current Filter: group 2. Also, I think the number of results might make sense to be on a different level. This might start to feel more organized if the search/filter control comes down to this level so that it's closer to the table. 19) If the user unselects the Select all available after filtering, it should still unselect all 4 matching nodes. In your example you've shown that only 2 of the 4 are unselected and then in screen 29 th user is in a weird state where they have unselected all matching nodes, but the table still shows that 2 nodes are selected. I think instead, it might make sense to have a Select All/Unselected All action at the table level. Thanks -- Jarda ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Tempest] Do we need more people reviewing tempest?
I recently submitted a _tiny_ change to tempest to enable Python3 porting in python-keystoneclient. https://review.openstack.org/#/c/51736/ It has one +2 now, but 8 days after submitting it is still waiting for a second +2. It is not special though, there are 59 waiting on reviewer: http://russellbryant.net/openstack-stats/tempest-openreviews.html Do we need to put out a call for more people to do reviews on tempest? Is the team just temporarily short-handed? Anyway, tempest is pretty important to OpenStack quality, so it feels like something we should all be helping with. I'd be happy to carve out a small bit of my usual review time to do tempest reviews, but I don't think I can solve the problem with what I can add. Since we all bring knowledge of the systems being tested, I wonder if all core reviewers from all projects can commit just a little time to tempest (rather than just having the core reviewers for tempest be a small team) ? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] HOT Software configuration proposal
On 22/10/13 16:35, Thomas Spatzier wrote:
Zane Bitter zbit...@redhat.com wrote on 22.10.2013 15:24:28:
From: Zane Bitter zbit...@redhat.com
To: openstack-dev@lists.openstack.org,
Date: 22.10.2013 15:27
Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
On 22/10/13 09:15, Thomas Spatzier wrote:
BTW, the convention of properties being input and attributes being
output,
i.e. that subtle distinction between properties and attributes is not
really intuitive, at least not to me as non-native speaker, because I
used
to use both words as synonyms.
As a native speaker, I can confidently state that it's not intuitive to
anyone ;)
Phew, good to read that ;-)
We unfortunately inherited these names from the Properties section and
the Fn::GetAtt function in cfn templates. It's even worse than that,
because there's a whole category of... uh... things (DependsOn,
DeletionPolicy, c.) that don't even have a name - I always have to
resist the urge to call them 'attributes' too.
So is this something we should try to get straight in HOT while we still
have the flexibility?
Y-yes. Provided that we can do it without making things *more*
confusing, +1. That's hard though, because there are a number of places
we have to refer to them, all with different audiences:
- HOT users
- cfn users
- Existing developers
- New developers
- Plugin developers
and using different names for the same thing can cause problems. My test
for this is: if you were helping a user on IRC debug an issue, is there
a high chance you would spend 15 minutes talking past each other because
they misunderstand the terminology?
Regarding properties/attributes for example, to me I would call both just
properties of a resource or component, and then I can write them or read
them like:
components:
my_component:
type: ...
properties:
my_prop: { get_property: [ other_component, other_component_prop ] }
other_component:
# ...
I.e. you write property 'my_prop' of 'my_component' in its properties
section, and you read property 'other_component_prop' of 'other_component'
using the get_property function.
... we can also call them attributes, but use one name, not two different
names for the same thing.
IMO inputs (Properties) and outputs (Fn::GetAtt) are different things
(and they exist in different namespaces), so -1 for giving them the same
name.
In an ideal world I'd like HOT to use something like get_output_data (or
maybe just get_data), but OTOH we have e.g. FnGetAtt() and
attributes_schema baked in to the plugin API that we can't really
change, so it seems likely to lead to developers and users adopting
different terminology, or making things very difficult for new
developers, or both :(
cheers,
Zane.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] IPv6 DHCP options for dnsmasq
On Tue, Oct 22, 2013 at 08:58:52AM +0200, Luke Gorrie wrote: Deutsche Telekom too. We are working on making Neutron interoperate well with a service provider network that's based on IPv6. I look forward to talking about this with people in Hong Kong :) I may be mistaken, but I don't see a summit proposal for Neutron, on the subject of IPv6. Are there plans to have one? -- Sean M. Collins pgpFNUoI1OtIP.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance
Are you saying you must have a default version defined to have 1 active versions? No, my point was using a default version field in the db rather than also picking from active versions may be confusing. From: Michael Basnight [mbasni...@gmail.com] Sent: Monday, October 21, 2013 4:04 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance On Oct 21, 2013, at 1:40 PM, Tim Simpson wrote: 2. I also think a datastore_version alone should be sufficient since the associated datastore type will be implied: When i brought this up it was generally discussed as being confusing. Id like to use type and rely on having a default (or active) version behind the scenes. Can't we do both? If a user wants a specific version, most likely they had to enumerate all datastore_versions, spot it in a list, and grab the guid. Why force them to also specify the datastore_type when we can easily determine what that is? Fair enough. 4. Additionally, in the current pull request to implement this it is possible to avoid passing a version, but only if no more than one version of the datastore_type exists in the database. I think instead the datastore_type row in the database should also have a default_version_id property, that an operator could update to the most recent version or whatever other criteria they wish to use, meaning the call could become this simple: Since we have determined from this email thread that we have an active status, and that 1 version can be active, we have to think about the precedence of active vs default. My question would be, if we have a default_version_id and a active version, what do we choose on behalf of the user? If there is 1 active version and a user does not specify the version, the api will error out, unless a default is defined. We also need a default_type in the config so the existing APIs can maintain compatibility. We can re-discuss this for v2 of the API. Imagine that an operator sets up Trove and only has one active version. They then somehow fumble setting up the default_version, but think they succeeded as the API works for users the way they expect anyway. Then they go to add another active version and suddenly their users get error messages. If we only use the default_version field of the datastore_type to define a default would honor the principle of least surprise. Are you saying you must have a default version defined to have 1 active versions? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance
This is also true that we dont want to define the _need_ to have custom images for the datastores. You can, quite easily, deploy mysql or redis on a vanilla image. Additionally there could be server code at some point soon that will need to know what datastore type is associated with an instance to determine what db engine is in use. So for example, if a call such as users isn't supported by a certain datastore used by an instance, the server side code will be able to determine that and something such as a bad request or not found status code. From: Michael Basnight [mbasni...@gmail.com] Sent: Monday, October 21, 2013 4:05 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance On Oct 21, 2013, at 1:57 PM, Nikhil Manchanda wrote: The image approach works fine if Trove only supports deploying a single datastore type (mysql in your case). As soon as we support deploying more than 1 datastore type, Trove needs to have some knowledge of which guestagent manager classes to load. Hence the need for having a datastore type API. The argument for needing to keep track of the version is similar. Potentially a version increment -- especially of the major version -- may require for a different guestagent manager. And Trove needs to have this information. This is also true that we dont want to define the _need_ to have custom images for the datastores. You can, quite easily, deploy mysql or redis on a vanilla image. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)
Excerpts from Monty Taylor's message of 2013-10-21 17:09:41 -0700: On 10/21/2013 10:44 PM, Clint Byrum wrote: Excerpts from Mark McLoughlin's message of 2013-10-21 13:45:21 -0700: If you don't know who the copyright holders are, you cannot know that the license being granted is actually enforceable. What if the Trove developers just found some repo lying out in the world and slapped an Apache license on it? We aren't going to do an ehaustive investigation, but we want to know _who_ granted said license. You know I think you're great, but this argument doesn't hold up. If the trove developers found some repo in the world and slapped an apache license AND said: Copyright 2012 Michael Basnight in the header, and Thomas put that in debian/copyright, the Debian FTP masters would very happily accept it. The copyright header is a data point. Now somebody looking to vet the license situation can go and contact Michael Basnight, and look at the history of the code itself. They can validate that Michael Basnight was an early author, made announcements, isn't a habitual code stealer, etc. Is this correct? No, but it gives someone looking to do due diligence confirmation that Michael had the right to license the code. No headers, and no information anywhere just makes an investigation that much harder. So it is just a data point for auditing. The problem, which Robert Collins alluded to, is that nobody is actually auditing things this way. This is something to bring up in Debian. I think I'll work off list with Thomas to draft something for Debian which proposes a clarification or relaxation of the copyright holder interpretation of Debian policy currently adopted by the FTP masters. I think that authors should attribute their work, because I think that they should care. However, if they don't, that's fine. There is SOME attribution in the file, and that attribution itself is correct. HP did write some of the file. Rackspace also did but did not bother to claim having done so. debian/copyright should reflect what's in the files - it's what the project is stating through the mechanisms that we have available to us. I appreciate Thomas trying to be more precise here, but I think it's actually too far. If you think that there is a bug in the copyright header, you need to contact the project, via email, bug or patch, and fix it. At THAT point, you can fix the debian/copyright file. Until then, you need to declare to Debian what we are declaring to you. Indeed, this hasn't come up, presumably, because the other debian/copyright files have done just that. That is definitely the path of least resistance, and the one I have taken. This is not trivial either, As somebody who made a feeble attempt at documenting the copyright holders for MySQL (all of you reading this have no idea how hard Monty is cackling right now), I can say that it is basically pointless to do anything except automatically generate from existing sources and spot check. I'm not sure that was me, but I would object to conflating it, yes. They are not the same thing, but they are related. Only a copyright holder can grant a copyright license. Listing the holders in debian/copyright does not prove that the asserted holder is a valid holder. It only asserts that _someone_ has asserted that copyright. It means that, should someone sue you for copyright infringement, there is someone you can go to for clarification. That sounds pretty valuable to me. Imagine Debian has some big corporation sending them cease and desist letters and threats of copyright infringement lawsuits. It would be useful to be able to deflect that efficiently given their limited resources. Our CLA process for new contributors is documented here: https://wiki.openstack.org/wiki/How_To_Contribute#Contributors_License_Agreement The key thing for Debian to understand is that all OpenStack contributors agree to license their code under the terms of the Apache License. I don't see why a list of copyright holders would clarify the licensing situation any further. So Debian has a rule that statements like these need to be delivered to their users along with the end-user binaries (it relates to the social contract and the guidelines attached to the contract. https://review.openstack.org/static/cla.html Article 2 is probably sufficient to say that it only really matters that all of the copyrighted material came from people who signed the CLA, and that the Project Manager (OpenStack Foundation) grants the license on the code. I assume the other CLA's have the same basic type of license being granted to the OpenStack Foundation. So my recommendation stands, that we can clarify it in the released tarballs with a single document. I suggest that document have the text of the CLA's (since there are different CLA's for different types of submitters), and an assertion
Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance
It's not intuitive to the User, if they are specifying a version alone. You don't boot a 'version' of something, with specifying what that some thing is. I would rather they only specified the datastore_type alone, and not have them specify a version at all. I agree for most users just selecting the datastore_type would be most intutive. However, when they specify a version it's going to a be GUID which they could only possibly know if they have recently enumerated all versions and thus *know* the version is for the given type they want. In that case I don't think most users would appreciate having to also pass the type- it would just be redundant. So in that case why not make it optional? From: Vipul Sabhaya [vip...@gmail.com] Sent: Monday, October 21, 2013 5:09 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance On Mon, Oct 21, 2013 at 2:04 PM, Michael Basnight mbasni...@gmail.commailto:mbasni...@gmail.com wrote: On Oct 21, 2013, at 1:40 PM, Tim Simpson wrote: 2. I also think a datastore_version alone should be sufficient since the associated datastore type will be implied: When i brought this up it was generally discussed as being confusing. Id like to use type and rely on having a default (or active) version behind the scenes. Can't we do both? If a user wants a specific version, most likely they had to enumerate all datastore_versions, spot it in a list, and grab the guid. Why force them to also specify the datastore_type when we can easily determine what that is? Fair enough. It's not intuitive to the User, if they are specifying a version alone. You don't boot a 'version' of something, with specifying what that some thing is. I would rather they only specified the datastore_type alone, and not have them specify a version at all. 4. Additionally, in the current pull request to implement this it is possible to avoid passing a version, but only if no more than one version of the datastore_type exists in the database. I think instead the datastore_type row in the database should also have a default_version_id property, that an operator could update to the most recent version or whatever other criteria they wish to use, meaning the call could become this simple: Since we have determined from this email thread that we have an active status, and that 1 version can be active, we have to think about the precedence of active vs default. My question would be, if we have a default_version_id and a active version, what do we choose on behalf of the user? If there is 1 active version and a user does not specify the version, the api will error out, unless a default is defined. We also need a default_type in the config so the existing APIs can maintain compatibility. We can re-discuss this for v2 of the API. Imagine that an operator sets up Trove and only has one active version. They then somehow fumble setting up the default_version, but think they succeeded as the API works for users the way they expect anyway. Then they go to add another active version and suddenly their users get error messages. If we only use the default_version field of the datastore_type to define a default would honor the principle of least surprise. Are you saying you must have a default version defined to have 1 active versions? I think it makes sense to have a 'Active' flag on every version -- and a default flag for the version that should be used as a default in the event the user doesn't specify. It also makes sense to require the deployer to set this accurately, and if one doesn't exist instance provisioning errors out. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Hyper-V meeting minutes
Hi All, Here are the minutes from today's meeting. Minutes: http://eavesdrop.openstack.org/meetings/hyper_v/2013/hyper_v.2013-10-22-16.01.html Minutes (text): http://eavesdrop.openstack.org/meetings/hyper_v/2013/hyper_v.2013-10-22-16.01.txt Log: http://eavesdrop.openstack.org/meetings/hyper_v/2013/hyper_v.2013-10-22-16.01.log.html Peter J. Pouliot, CISSP Senior SDET, OpenStack Microsoft New England Research Development Center One Memorial Drive,Cambridge, MA 02142 ppoul...@microsoft.commailto:ppoul...@microsoft.com | Tel: +1(857) 453 6436 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] CLA
On 22/10/13 16:22, Jeremy Stanley wrote: (Disclaimers: I am not a lawyer, which likely explains my lack of interest in perversely pointless paperwork. Also, these opinions are my own and do not necessarily reflect those of my employer. Setting MFT to legal-discuss as a more appropriate forum for these sorts of discussions.) On 2013-10-22 15:11:25 +0200 (+0200), Zane Bitter wrote: [...] Can't we just write Copyright OpenStack Contributors? (Where 'contributors' means individuals or organisations who have signed the CLA.) [...] Actually, technically not. There are other avenues through which patches come (posts on mailing lists, attachments to bugs) and I know that from time to time contributors git-am other authors' bug fixes without first asking them to go agree to an OpenStack CLA and prove that they have done so. The actual copyright belongs with the author (or their employer under a work-for-hire agreement), not the contributor who uploaded that work--and they aren't necessarily always the same people. Fair point, although as you note below if the contributor does not identify the actual copyright holder in the submission, that is their responsibility not OpenStack's responsibility. Likely a few copyright holders will fall through the cracks here (e.g. from legitimately identified external code like https://review.openstack.org/#/c/40330/), but many, many *more* will fall through the cracks in trying to compile a list of them. I'm not suggesting here that the CLA can provide an accurate list of copyright holders (which is impossible anyway), I'm saying that it provides a paper-trail back to somebody who warrants that they have the right to licence the code under the ASL (however mistaken they may be about that), and that this is precisely the paper trail that the Debian FTP masters are looking for. Gerrit ensures that only OpenStack Contributors (those that have signed the CLA) can contribute to OpenStack [...] To echo Monty's sentiments earlier in the thread, and also as the person who spear-headed the current CLA enforcement configuration in our project's Gerrit instance, I don't see how our CLAs add anything of value. It's patronizing, almost insulting, to ask developers to pinky-swear that they're authorized to license the code they contribute under the license included with the code they contribute. It's exactly as silly as Debian requiring the copyright holders to be identified alongside the licence. As an engineer, I'm inclined to agree that it's pretty silly, because it doesn't actually change anything - nobody is ever surprised when their contribution to open source ends up as open source, and if it turns out that they were not entitled to so licence it then it's still effectively everyone's problem, CLA or no. Clearly there are lawyers who disagree though. At best it may provide a warm fuzzy feeling for companies who are unfamiliar with contributing to free software projects, since free software licenses are all about waiving your rights rather than enforcing them and that might sound scary to the uninitiated... but better efforts toward educating them about free software may prove more productive than relying on a legal security blanket. Also as mentioned above, Gerrit does not enforce that the copyright holder has agreed to this, it only enforces that the person *uploading* the code into Gerrit has agreed to it... and section 7 of the ICLA has some interesting things to say about submitting third-party contributions, which looks to me like a permitted loophole for getting ASL code into the project without the author directly agreeing to a CLA at all. 7. Should You wish to submit work that is not Your original creation, You may submit it to the Project Manager separately from any Contribution, identifying the complete details of its source and of any license or other restriction (including, but not limited to, related patents, trademarks, and license agreements) of which you are personally aware, and conspicuously marking the work as Submitted on behalf of a third-party: [named here]. I wonder if the current de facto practice of allowing git's author header to reflect the identity of the third-party counts as a conspicuous mark for the purposes of ICLA section 7? And whether submitting it to Gerrit where it can be openly inspected by the entire project counts as a submission to the Project Manager (the OpenStack Foundation) as well? At any rate, it seems that the agreement boils down to copyright holders promise that they're contributing code under this license, or that they're submitting someone else's work who probably is okay with it. That's exactly what it boils down to, and coincidentally exactly what the requirement to list copyright holders in Debian also boils down to afaict. We should leverage the synergies, or something ;) cheers, Zane. ___ OpenStack-dev mailing list
Re: [openstack-dev] [Heat] HOT Software configuration proposal
Zane Bitter zbit...@redhat.com wrote on 22.10.2013 17:23:52:
From: Zane Bitter zbit...@redhat.com
To: openstack-dev@lists.openstack.org,
Date: 22.10.2013 17:26
Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
On 22/10/13 16:35, Thomas Spatzier wrote:
Zane Bitter zbit...@redhat.com wrote on 22.10.2013 15:24:28:
From: Zane Bitter zbit...@redhat.com
To: openstack-dev@lists.openstack.org,
Date: 22.10.2013 15:27
Subject: Re: [openstack-dev] [Heat] HOT Software configuration
proposal
On 22/10/13 09:15, Thomas Spatzier wrote:
BTW, the convention of properties being input and attributes being
output,
i.e. that subtle distinction between properties and attributes is not
really intuitive, at least not to me as non-native speaker, because I
used
to use both words as synonyms.
As a native speaker, I can confidently state that it's not intuitive
to
anyone ;)
Phew, good to read that ;-)
We unfortunately inherited these names from the Properties section and
the Fn::GetAtt function in cfn templates. It's even worse than that,
because there's a whole category of... uh... things (DependsOn,
DeletionPolicy, c.) that don't even have a name - I always have to
resist the urge to call them 'attributes' too.
So is this something we should try to get straight in HOT while we
still
have the flexibility?
Y-yes. Provided that we can do it without making things *more*
confusing, +1. That's hard though, because there are a number of places
we have to refer to them, all with different audiences:
- HOT users
- cfn users
- Existing developers
- New developers
- Plugin developers
and using different names for the same thing can cause problems. My test
for this is: if you were helping a user on IRC debug an issue, is there
a high chance you would spend 15 minutes talking past each other because
they misunderstand the terminology?
Hm, good point. Seems like it would really cause more confusion than it
helps. So back away from the general idea of renaming things that exist
both in cfn and HOT.
What we should try of course is to give new concepts that will only exist
in HOT intuitive names.
Regarding properties/attributes for example, to me I would call both
just
properties of a resource or component, and then I can write them or
read
them like:
components:
my_component:
type: ...
properties:
my_prop: { get_property: [ other_component,
other_component_prop ] }
other_component:
# ...
I.e. you write property 'my_prop' of 'my_component' in its properties
section, and you read property 'other_component_prop' of
'other_component'
using the get_property function.
... we can also call them attributes, but use one name, not two
different
names for the same thing.
IMO inputs (Properties) and outputs (Fn::GetAtt) are different things
(and they exist in different namespaces), so -1 for giving them the same
name.
In an ideal world I'd like HOT to use something like get_output_data (or
maybe just get_data), but OTOH we have e.g. FnGetAtt() and
attributes_schema baked in to the plugin API that we can't really
change, so it seems likely to lead to developers and users adopting
different terminology, or making things very difficult for new
developers, or both :(
cheers,
Zane.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] IPv6 DHCP options for dnsmasq
FWIW, we've wanted IPv6 support too but there are limitations in sqlalchemy and python 2.6 and since openstack is still supporting both of those, we are gated on that. Thanks, MATT RIEDEMANN Advisory Software Engineer Cloud Solutions and OpenStack Development Phone: 1-507-253-7622 | Mobile: 1-507-990-1889 E-mail: mrie...@us.ibm.com 3605 Hwy 52 N Rochester, MN 55901-1407 United States From: Sean M. Collins s...@coreitpro.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org, Date: 10/22/2013 10:33 AM Subject:Re: [openstack-dev] [Neutron] IPv6 DHCP options for dnsmasq On Tue, Oct 22, 2013 at 08:58:52AM +0200, Luke Gorrie wrote: Deutsche Telekom too. We are working on making Neutron interoperate well with a service provider network that's based on IPv6. I look forward to talking about this with people in Hong Kong :) I may be mistaken, but I don't see a summit proposal for Neutron, on the subject of IPv6. Are there plans to have one? -- Sean M. Collins [attachment att18car.dat deleted by Matt Riedemann/Rochester/IBM] ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev image/gif___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Debian Jessie freeze date announced: 5th of November 2014
On 10/20/2013 05:25 AM, Cristian Tomoiaga wrote: Hello Thomas, I am sorry to send a reply a little late on this. I plan on working with Debian for my Openstack setups (now I'm on a rhel based setup) and I would really like the latest OpenStack release available. I was initially planning to setup my own mirrors since I always seem to need features from the next OpenStack release. For example Grizzly for me looks too old and some features that were supposed to land on Havana are now scheduled for Icehouse. Given this, I would pretty much like to have J in Debian Jessie. I'm not sure how to approach this or if it's worth the effort on your part given the latest issues you submitted for Havana and since most likely some features in K will probably make me switch to separate mirrors anyway. However, taking into account the rapid development of OpenStack my guess is that the J release should land in Jessie if possible. I will also try to find some time and help out as much as I can with this. Let me know what you decide , probably after the summit. Hi Cristian, Thanks for your above comments. Unfortunately, even if I agree with you that the latest is best, and that having a maximum of feature is just cool, my decision will *not* be motivated by that. The only thing will care will be the ease maintainability in the Debian stable release. Maintaining security for OpenStack Essex in Wheezy is currently a major pain, because it's not supported upstream. It'd be really great, from my point of view, if the OpenStack community decided to have an LTS release. Maybe it didn't make sense at the time of Essex. Probably, as the time passes and OpenStack matures, it will make more sense now and later to have an LTS. Though this isn't my decision, and my understanding of it, is that the amount of people interested by doing the security backport work this is close to one (eg: only myself). So, if there's still no LTS for OpenStack next April, and things continue to be maintained the way they are right now in OpenStack (that is, release + 1 year), then I have 2 options. Either I will follow Canonical, and hope that we can have a joined effort for security fixing (currently, it's not happening at all, so this would have to change), or just package the very latest (release J), so that backporting of patches is less painful that backporting to Icehouse. This way, I'd also get 1 year of free security support instead of 6 months, which is something already... Also, another problem is being able to get enough patches of the point release into the frozen Testing distribution. When OpenStack releases, there's always a bug here and there that are annoying, but discovered later, on point releases. So 2013.1.4 could make more sense, quality wise, as it will have the time to be polished and cleaned. Wheezy has been released with 2012.1.1, and not 2012.1.4, because it was frozen at the end of June, and nobody took care of applying the upstream patches and convincing the release team that they are needed. To get this happening with the J release of OpenStack, every patch will be reviewed and will need justification, which takes a lot of time for both the package maintainer and the release team, so it'd be nice to avoid it. Last thing: I will need to support upgrades from Essex to whatever will be in Jessie. It'd be nice if I can avoid doing this alone. I'm not sure if the OpenStack project is bound to support that, or if Canonical will be doing the work. Oh, and one last thing: whatever happen, I will continue to package the very latest OpenStack version either in Sid, or in Experimental, and continue to provide Wheezy / Jessie backports. So if you want the very latest version of OpenStack in Debian, you'll have it available. I hope the above gives you a more clear picture of what's going on in my mind. I have a year to take a decision... :) Cheers, Thomas Goirand (zigo) P.S: CC-ing the Debian release team list, to get their opinion. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Common requirements for services' discussion
Hi All, Here is a log of today's discussion: http://eavesdrop.openstack.org/meetings/networking_advanced_services/2013/networking_advanced_services.2013-10-22-15.32.log.html (some action items for a few folks who were present, we will follow up in the next meeting.) Thanks, ~Sumit. On Mon, Oct 21, 2013 at 11:08 PM, Sumit Naiksatam sumitnaiksa...@gmail.comwrote: Hi All, This is a reminder for the next IRC meeting on Tuesday (Oct 22nd) 15.30 UTC (8.30 AM PDT) on the #openstack-meeting-alt channel. The proposed agenda is: * Service insertion and chaining * Service agents * Service VMs - mechanism * Service VMs - policy * Extensible APIs for services and anything else you may want to discuss in this context. Meeting wiki page (has pointer to the first meeting logs): https://wiki.openstack.org/wiki/Meetings/AdvancedServices Thanks, ~Sumit. On Thu, Oct 17, 2013 at 12:02 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: Hi All, We will have the advanced services and the common requirements IRC meeting on Tuesdays 15.30 UTC (8.30 AM PDT) on the #openstack-meeting-alt channel. The meeting time was chosen to accommodate requests by folks in Asia and will hopefully suit most people involved. Please note that this is the alternate meeting channel. The agenda will be a continuation of discussion from the previous meeting with some additional agenda items based on the sessions already proposed for the summit. The current discussion is being captured in this etherpad: https://etherpad.openstack.org/p/NeutronAdvancedServices Hope you can make it and participate. Thanks, ~Sumit. On Mon, Oct 14, 2013 at 8:15 PM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: Thanks all for attending the IRC meeting today for the Neutron advanced services discussion. We have an etherpad for this: https://etherpad.openstack.org/p/NeutronAdvancedServices It was also felt that we need to have more ongoing discussions, so we will have follow up meetings. We will try to propose a more convenient time for everyone involved for a meeting next week. Meanwhile, we can continue to use the mailing list, etherpad, and/or comment on the specific proposals. Thanks, ~Sumit. On Tue, Oct 8, 2013 at 8:30 PM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: Hi All, We had a VPNaaS meeting yesterday and it was felt that we should have a separate meeting to discuss the topics common to all services. So, in preparation for the Icehouse summit, I am proposing an IRC meeting on Oct 14th 22:00 UTC (immediately after the Neutron meeting) to discuss common aspects related to the FWaaS, LBaaS, and VPNaaS. We will begin with service insertion and chaining discussion, and I hope we can collect requirements for other common aspects such as service agents, services instances, etc. as well. Etherpad for service insertion chaining can be found here: https://etherpad.openstack.org/icehouse-neutron-service-insertion-chaining Hope you all can join. Thanks, ~Sumit. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] HOT Software configuration proposal
Hello,
I've been reading through the thread and the wiki pages and I'm still
confused by the terms. Is there a clear definition of what do we understand
by component from user's and developer's point of view. If I write
component, type:MySQL what is behind that definition? I mean how does the
system know what exactly MySQL is and how to install it? What MySQL version
is it gonna be? Will it be x86 or x64? How does the system understand that
I need MySQL for Windows on Windows VM rather then Linux MySQL? What do I
as a developer need to do so that it would be possible to have type:
MyCoolComponentType?
On Tue, Oct 22, 2013 at 8:35 PM, Thomas Spatzier thomas.spatz...@de.ibm.com
wrote:
Zane Bitter zbit...@redhat.com wrote on 22.10.2013 17:23:52:
From: Zane Bitter zbit...@redhat.com
To: openstack-dev@lists.openstack.org,
Date: 22.10.2013 17:26
Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
On 22/10/13 16:35, Thomas Spatzier wrote:
Zane Bitter zbit...@redhat.com wrote on 22.10.2013 15:24:28:
From: Zane Bitter zbit...@redhat.com
To: openstack-dev@lists.openstack.org,
Date: 22.10.2013 15:27
Subject: Re: [openstack-dev] [Heat] HOT Software configuration
proposal
On 22/10/13 09:15, Thomas Spatzier wrote:
BTW, the convention of properties being input and attributes being
output,
i.e. that subtle distinction between properties and attributes is not
really intuitive, at least not to me as non-native speaker, because I
used
to use both words as synonyms.
As a native speaker, I can confidently state that it's not intuitive
to
anyone ;)
Phew, good to read that ;-)
We unfortunately inherited these names from the Properties section and
the Fn::GetAtt function in cfn templates. It's even worse than that,
because there's a whole category of... uh... things (DependsOn,
DeletionPolicy, c.) that don't even have a name - I always have to
resist the urge to call them 'attributes' too.
So is this something we should try to get straight in HOT while we
still
have the flexibility?
Y-yes. Provided that we can do it without making things *more*
confusing, +1. That's hard though, because there are a number of places
we have to refer to them, all with different audiences:
- HOT users
- cfn users
- Existing developers
- New developers
- Plugin developers
and using different names for the same thing can cause problems. My test
for this is: if you were helping a user on IRC debug an issue, is there
a high chance you would spend 15 minutes talking past each other because
they misunderstand the terminology?
Hm, good point. Seems like it would really cause more confusion than it
helps. So back away from the general idea of renaming things that exist
both in cfn and HOT.
What we should try of course is to give new concepts that will only exist
in HOT intuitive names.
Regarding properties/attributes for example, to me I would call both
just
properties of a resource or component, and then I can write them or
read
them like:
components:
my_component:
type: ...
properties:
my_prop: { get_property: [ other_component,
other_component_prop ] }
other_component:
# ...
I.e. you write property 'my_prop' of 'my_component' in its properties
section, and you read property 'other_component_prop' of
'other_component'
using the get_property function.
... we can also call them attributes, but use one name, not two
different
names for the same thing.
IMO inputs (Properties) and outputs (Fn::GetAtt) are different things
(and they exist in different namespaces), so -1 for giving them the same
name.
In an ideal world I'd like HOT to use something like get_output_data (or
maybe just get_data), but OTOH we have e.g. FnGetAtt() and
attributes_schema baked in to the plugin API that we can't really
change, so it seems likely to lead to developers and users adopting
different terminology, or making things very difficult for new
developers, or both :(
cheers,
Zane.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Sincerely yours
Stanislav (Stan) Lagun
Senior Developer
Mirantis
35b/3, Vorontsovskaya St.
Moscow, Russia
Skype: stanlagun
www.mirantis.com
sla...@mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] IPv6 DHCP options for dnsmasq
On 10/22/2013 12:48 PM, Matt Riedemann wrote: FWIW, we've wanted IPv6 support too but there are limitations in sqlalchemy and python 2.6 and since openstack is still supporting both of those, we are gated on that. What limitations re: IPv6 does SQLAlchemy present? -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Trove] How users should specify a datastore type when creating an instance
On Oct 22, 2013, at 9:34 AM, Tim Simpson wrote: It's not intuitive to the User, if they are specifying a version alone. You don't boot a 'version' of something, with specifying what that some thing is. I would rather they only specified the datastore_type alone, and not have them specify a version at all. I agree for most users just selecting the datastore_type would be most intutive. However, when they specify a version it's going to a be GUID which they could only possibly know if they have recently enumerated all versions and thus *know* the version is for the given type they want. In that case I don't think most users would appreciate having to also pass the type- it would just be redundant. So in that case why not make it optional?] im ok w/ making either optional if the criteria for selecting the _other_ is not ambiguous. signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Error while executing 'git review'
On 10/22/2013 06:04 AM, S Sridhar wrote: But getting following error while posting for review. sridhar@ubuntu:~/repo/neutron$ git review remote: Resolving deltas: 100% (4/4) remote: Processing changes: refs: 1, done To ssh://saggezz...@review.openstack.org:29418/openstack/neutron.git ! [remote rejected] HEAD - refs/for/master/bug/1176683 (change 52949 closed) error: failed to push some refs to 'ssh://saggezz...@review.openstack.org:29418/openstack/neutron.git' sridhar@ubuntu:~/repo/neutron$ Could anyone help in resolving this issue ? Glad to read the issue was solved. To prevent this from happening in the future please follow the suggested 'normal' workflow https://wiki.openstack.org/wiki/GerritWorkflow#Normal_Workflow HTH /stef -- 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] openstack-dev][nova][neturon] NoopFirewallDriver lead nova boot/show/list failure.
Hi, When firewall_driver is set to NoopFirwallDriver in Neutron agent, uses can create security group and its rules, but no packet filtering is enforced. If neutron security group is enabled, users should expect packet filtering is enabled I think this behavior is confusing from Neutron API perspective, and if no packet filtering is enforced, we cannot say security group feature is provided. This is the background of the change. In my thoughts there are three players here, the developer, the administrator and the users (close to what is the API perspective in your terms). If the administrator decides to use the noop implementation of an API and he does not tell his users this is the case, that's definitely confusing for the users. If the administrator wants to use the noop implementation and instead of getting a noop behaviour the whole extension disappears that's also confusing, but for the administrator. I also get that an API user typically does not know the configuration against his code will run. The noop implementation cannot be turned on accidentally. The administrator has to do it for whatever reason - likely debugging as you mentioned. I believe it's not the developer's responsibility to protect the users from the administrator's intentional configuration decision. Anyway I can live with the other proposed alternatives too. I just wanted to point out that for me the current behavior was the surprising one. And also wanted to connect the discussion to its origins. Thanks, Bence ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] IPv6 DHCP options for dnsmasq
I am guessing Matt is talking about running openstack in a pure ipv6 environment. So it would be this bug https://bugs.launchpad.net/nova/+bug/1190454 On Tue, Oct 22, 2013 at 1:10 PM, Jay Pipes jaypi...@gmail.com wrote: On 10/22/2013 12:48 PM, Matt Riedemann wrote: FWIW, we've wanted IPv6 support too but there are limitations in sqlalchemy and python 2.6 and since openstack is still supporting both of those, we are gated on that. What limitations re: IPv6 does SQLAlchemy present? -jay __**_ OpenStack-dev mailing list OpenStack-dev@lists.openstack.**org OpenStack-dev@lists.openstack.org http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-devhttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] A prototype for cross-vm synchronization and communication
Hi Steven, Steven Hardy sha...@redhat.com wrote on 10/21/2013 11:27:43 AM: On Fri, Oct 18, 2013 at 02:45:01PM -0400, Lakshminaraya Renganarayana wrote: snip The prototype is implemented in Python and Ruby is used for chef interception. Where can we find the code? What part of the code are you interested in? The python pre-processor part or the Ruby chef interceptor part? I need to get clearance from IBM to post it on the Git. I am guessing it might be easy to get clearance for the pre-processor code and a bit harder for the chef interceptor code. BTW, will you be attending the OpenStack summit in HongKong? I am planning to and I can show you a demo of this pre-processor there (if the IBM clearance takes too long). Thanks, LN___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)
Top posting cuz im a baller. We will get this fixed today. PS clint i like the way you think ;) https://review.openstack.org/#/c/53176/ On Oct 22, 2013, at 9:21 AM, Clint Byrum wrote: Excerpts from Monty Taylor's message of 2013-10-21 17:09:41 -0700: On 10/21/2013 10:44 PM, Clint Byrum wrote: Excerpts from Mark McLoughlin's message of 2013-10-21 13:45:21 -0700: If you don't know who the copyright holders are, you cannot know that the license being granted is actually enforceable. What if the Trove developers just found some repo lying out in the world and slapped an Apache license on it? We aren't going to do an ehaustive investigation, but we want to know _who_ granted said license. You know I think you're great, but this argument doesn't hold up. If the trove developers found some repo in the world and slapped an apache license AND said: Copyright 2012 Michael Basnight in the header, and Thomas put that in debian/copyright, the Debian FTP masters would very happily accept it. The copyright header is a data point. Now somebody looking to vet the license situation can go and contact Michael Basnight, and look at the history of the code itself. They can validate that Michael Basnight was an early author, made announcements, isn't a habitual code stealer, etc. Is this correct? No, but it gives someone looking to do due diligence confirmation that Michael had the right to license the code. No headers, and no information anywhere just makes an investigation that much harder. So it is just a data point for auditing. The problem, which Robert Collins alluded to, is that nobody is actually auditing things this way. This is something to bring up in Debian. I think I'll work off list with Thomas to draft something for Debian which proposes a clarification or relaxation of the copyright holder interpretation of Debian policy currently adopted by the FTP masters. I think that authors should attribute their work, because I think that they should care. However, if they don't, that's fine. There is SOME attribution in the file, and that attribution itself is correct. HP did write some of the file. Rackspace also did but did not bother to claim having done so. debian/copyright should reflect what's in the files - it's what the project is stating through the mechanisms that we have available to us. I appreciate Thomas trying to be more precise here, but I think it's actually too far. If you think that there is a bug in the copyright header, you need to contact the project, via email, bug or patch, and fix it. At THAT point, you can fix the debian/copyright file. Until then, you need to declare to Debian what we are declaring to you. Indeed, this hasn't come up, presumably, because the other debian/copyright files have done just that. That is definitely the path of least resistance, and the one I have taken. This is not trivial either, As somebody who made a feeble attempt at documenting the copyright holders for MySQL (all of you reading this have no idea how hard Monty is cackling right now), I can say that it is basically pointless to do anything except automatically generate from existing sources and spot check. I'm not sure that was me, but I would object to conflating it, yes. They are not the same thing, but they are related. Only a copyright holder can grant a copyright license. Listing the holders in debian/copyright does not prove that the asserted holder is a valid holder. It only asserts that _someone_ has asserted that copyright. It means that, should someone sue you for copyright infringement, there is someone you can go to for clarification. That sounds pretty valuable to me. Imagine Debian has some big corporation sending them cease and desist letters and threats of copyright infringement lawsuits. It would be useful to be able to deflect that efficiently given their limited resources. Our CLA process for new contributors is documented here: https://wiki.openstack.org/wiki/How_To_Contribute#Contributors_License_Agreement The key thing for Debian to understand is that all OpenStack contributors agree to license their code under the terms of the Apache License. I don't see why a list of copyright holders would clarify the licensing situation any further. So Debian has a rule that statements like these need to be delivered to their users along with the end-user binaries (it relates to the social contract and the guidelines attached to the contract. https://review.openstack.org/static/cla.html Article 2 is probably sufficient to say that it only really matters that all of the copyrighted material came from people who signed the CLA, and that the Project Manager (OpenStack Foundation) grants the license on the code. I assume the other CLA's have the same basic type of license being granted to the OpenStack Foundation. So my recommendation stands, that we can clarify it
Re: [openstack-dev] [Neutron] IPv6 DHCP options for dnsmasq
Interesting, thx! :) On 10/22/2013 01:18 PM, Davanum Srinivas wrote: I am guessing Matt is talking about running openstack in a pure ipv6 environment. So it would be this bug https://bugs.launchpad.net/nova/+bug/1190454 On Tue, Oct 22, 2013 at 1:10 PM, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com wrote: On 10/22/2013 12:48 PM, Matt Riedemann wrote: FWIW, we've wanted IPv6 support too but there are limitations in sqlalchemy and python 2.6 and since openstack is still supporting both of those, we are gated on that. What limitations re: IPv6 does SQLAlchemy present? -jay _ OpenStack-dev mailing list OpenStack-dev@lists.openstack.__org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ 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] [Heat] HOT Software configuration proposal
Hi,
I would agree with Stan that we need to discuss definitions before going
deeply to the implementation.
The first example on the
https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config shows
components like install_mysql and install_wordpress.
I would say that this is a bit confusing because I expected to see
component definitions instead of software deployment definition process. I
think this is a quite dangerous path here because this example shows us
that we can use components as installation steps definition instead of real
component definition.
If one continue to do this approach and defines more and more granular
steps as a components they will come to workflow definition composed in
terms of components. This approach does not add either simplicity or
clarity in the HOT template.
Thanks
Georgy
On Tue, Oct 22, 2013 at 10:02 AM, Stan Lagun sla...@mirantis.com wrote:
Hello,
I've been reading through the thread and the wiki pages and I'm still
confused by the terms. Is there a clear definition of what do we understand
by component from user's and developer's point of view. If I write
component, type:MySQL what is behind that definition? I mean how does the
system know what exactly MySQL is and how to install it? What MySQL version
is it gonna be? Will it be x86 or x64? How does the system understand that
I need MySQL for Windows on Windows VM rather then Linux MySQL? What do I
as a developer need to do so that it would be possible to have type:
MyCoolComponentType?
On Tue, Oct 22, 2013 at 8:35 PM, Thomas Spatzier
thomas.spatz...@de.ibm.com wrote:
Zane Bitter zbit...@redhat.com wrote on 22.10.2013 17:23:52:
From: Zane Bitter zbit...@redhat.com
To: openstack-dev@lists.openstack.org,
Date: 22.10.2013 17:26
Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
On 22/10/13 16:35, Thomas Spatzier wrote:
Zane Bitter zbit...@redhat.com wrote on 22.10.2013 15:24:28:
From: Zane Bitter zbit...@redhat.com
To: openstack-dev@lists.openstack.org,
Date: 22.10.2013 15:27
Subject: Re: [openstack-dev] [Heat] HOT Software configuration
proposal
On 22/10/13 09:15, Thomas Spatzier wrote:
BTW, the convention of properties being input and attributes being
output,
i.e. that subtle distinction between properties and attributes is
not
really intuitive, at least not to me as non-native speaker, because
I
used
to use both words as synonyms.
As a native speaker, I can confidently state that it's not intuitive
to
anyone ;)
Phew, good to read that ;-)
We unfortunately inherited these names from the Properties section
and
the Fn::GetAtt function in cfn templates. It's even worse than that,
because there's a whole category of... uh... things (DependsOn,
DeletionPolicy, c.) that don't even have a name - I always have to
resist the urge to call them 'attributes' too.
So is this something we should try to get straight in HOT while we
still
have the flexibility?
Y-yes. Provided that we can do it without making things *more*
confusing, +1. That's hard though, because there are a number of places
we have to refer to them, all with different audiences:
- HOT users
- cfn users
- Existing developers
- New developers
- Plugin developers
and using different names for the same thing can cause problems. My test
for this is: if you were helping a user on IRC debug an issue, is there
a high chance you would spend 15 minutes talking past each other because
they misunderstand the terminology?
Hm, good point. Seems like it would really cause more confusion than it
helps. So back away from the general idea of renaming things that exist
both in cfn and HOT.
What we should try of course is to give new concepts that will only exist
in HOT intuitive names.
Regarding properties/attributes for example, to me I would call both
just
properties of a resource or component, and then I can write them or
read
them like:
components:
my_component:
type: ...
properties:
my_prop: { get_property: [ other_component,
other_component_prop ] }
other_component:
# ...
I.e. you write property 'my_prop' of 'my_component' in its properties
section, and you read property 'other_component_prop' of
'other_component'
using the get_property function.
... we can also call them attributes, but use one name, not two
different
names for the same thing.
IMO inputs (Properties) and outputs (Fn::GetAtt) are different things
(and they exist in different namespaces), so -1 for giving them the same
name.
In an ideal world I'd like HOT to use something like get_output_data (or
maybe just get_data), but OTOH we have e.g. FnGetAtt() and
attributes_schema baked in to the plugin API that we can't really
change, so it seems likely to lead to developers and users adopting
different terminology,
[openstack-dev] [Glance] Team Meeting Reminder
Hi folks, Just reminding you that we'll have our meeting during the early timeslot this week, at 14:00 UTC on October 24th. In your locale, that's http://www.timeanddate.com/worldclock/fixedtime.html?msg=Glance+Meetingiso=20131022T14ah=1. The channel as always is #openstack-meeting-alt and all are welcome to attend. The agenda is currently forming at https://etherpad.openstack.org/p/glance-team-meeting-agenda so feel free to add any items you want to discuss. Cheers, markwash ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Common requirements for services' discussion
I am sorry that I missed this morning's meeting. Reading through the log, one thing that was briefly touch upon is to support Service Type Framework for L3 router service. As all other services (vpn, fw, lb, metering) will be integrated to the service framework in I-release, L3 router service, as a major building block, shouldn't be missed. What we are thinking is to make L3 agent as one of plugin-drivers of L3 router services. This seems to align with comments during the meeting. I wonder if there are enough interests to push this forward. Thanks, Gary On Tue, Oct 22, 2013 at 9:55 AM, Sumit Naiksatam sumitnaiksa...@gmail.comwrote: Hi All, Here is a log of today's discussion: http://eavesdrop.openstack.org/meetings/networking_advanced_services/2013/networking_advanced_services.2013-10-22-15.32.log.html (some action items for a few folks who were present, we will follow up in the next meeting.) Thanks, ~Sumit. On Mon, Oct 21, 2013 at 11:08 PM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: Hi All, This is a reminder for the next IRC meeting on Tuesday (Oct 22nd) 15.30 UTC (8.30 AM PDT) on the #openstack-meeting-alt channel. The proposed agenda is: * Service insertion and chaining * Service agents * Service VMs - mechanism * Service VMs - policy * Extensible APIs for services and anything else you may want to discuss in this context. Meeting wiki page (has pointer to the first meeting logs): https://wiki.openstack.org/wiki/Meetings/AdvancedServices Thanks, ~Sumit. On Thu, Oct 17, 2013 at 12:02 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: Hi All, We will have the advanced services and the common requirements IRC meeting on Tuesdays 15.30 UTC (8.30 AM PDT) on the #openstack-meeting-alt channel. The meeting time was chosen to accommodate requests by folks in Asia and will hopefully suit most people involved. Please note that this is the alternate meeting channel. The agenda will be a continuation of discussion from the previous meeting with some additional agenda items based on the sessions already proposed for the summit. The current discussion is being captured in this etherpad: https://etherpad.openstack.org/p/NeutronAdvancedServices Hope you can make it and participate. Thanks, ~Sumit. On Mon, Oct 14, 2013 at 8:15 PM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: Thanks all for attending the IRC meeting today for the Neutron advanced services discussion. We have an etherpad for this: https://etherpad.openstack.org/p/NeutronAdvancedServices It was also felt that we need to have more ongoing discussions, so we will have follow up meetings. We will try to propose a more convenient time for everyone involved for a meeting next week. Meanwhile, we can continue to use the mailing list, etherpad, and/or comment on the specific proposals. Thanks, ~Sumit. On Tue, Oct 8, 2013 at 8:30 PM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote: Hi All, We had a VPNaaS meeting yesterday and it was felt that we should have a separate meeting to discuss the topics common to all services. So, in preparation for the Icehouse summit, I am proposing an IRC meeting on Oct 14th 22:00 UTC (immediately after the Neutron meeting) to discuss common aspects related to the FWaaS, LBaaS, and VPNaaS. We will begin with service insertion and chaining discussion, and I hope we can collect requirements for other common aspects such as service agents, services instances, etc. as well. Etherpad for service insertion chaining can be found here: https://etherpad.openstack.org/icehouse-neutron-service-insertion-chaining Hope you all can join. Thanks, ~Sumit. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Distributed Virtual Router Discussion
Hi Artem, Very happy to see more stackers working on this feature. : ) Note that the images in your document are badly corrupted - maybe my questions could already be answered by your diagrams. I met the same issue at first. Downloading the doc and open it locally may help. It works for me. Also, a wiki page for DVR/VDR feature is created, including some interesting performance test output. Thanks. https://wiki.openstack.org/wiki/Distributed_Router_for_OVS Best, Robin Wang From: Artem Dmytrenko Date: 2013-10-22 02:51 To: yong sheng gong \(gong...@unitedstack.com\); cloudbe...@gmail.com; OpenStack Development Mailing List Subject: Re: [openstack-dev] Distributed Virtual Router Discussion Hi Swaminathan. I work for a virtual networking startup called Midokura and I'm very interested in joining the discussion. We currently have distributed router implementation using existing Neutron API. Could you clarify why distributed vs centrally located routing implementation need to be distinguished? Another question is that are you proposing distributed routing implementation for tenant routers or for the router connecting the virtual cloud to the external network? The reason that I'm asking this question is because our company would also like to propose a router implementation that would eliminate a single point uplink failures. We have submitted a couple blueprints on that topic (https://blueprints.launchpad.net/neutron/+spec/provider-router-support, https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing) and would appreciate an opportunity to collaborate on making it a reality. Note that the images in your document are badly corrupted - maybe my questions could already be answered by your diagrams. Could you update your document with legible diagrams? Looking forward to further discussing this topic with you! Sincerely, Artem Dmytrenko On Mon, 10/21/13, Vasudevan, Swaminathan (PNB Roseville) swaminathan.vasude...@hp.com wrote: Subject: [openstack-dev] Distributed Virtual Router Discussion To: yong sheng gong (gong...@unitedstack.com) gong...@unitedstack.com, cloudbe...@gmail.com cloudbe...@gmail.com, OpenStack Development Mailing List (openstack-dev@lists.openstack.org) openstack-dev@lists.openstack.org Date: Monday, October 21, 2013, 12:18 PM Hi Folks, I am currently working on a blueprint for Distributed Virtual Router. If anyone interested in being part of the discussion please let me know. I have put together a first draft of my blueprint and have posted it on Launchpad for review. https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr 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.com -Inline Attachment Follows- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Distributed Virtual Router Discussion
Hi Folks, Thanks for your interests in the DVR feature. We should get together to start discussing the details in the DVR. Please let me know who else is interested, probably the time slot and we can start nailing down the details. https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr https://wiki.openstack.org/wiki/Distributed_Router_for_OVS Thanks Swami From: Robin Wang [mailto:cloudbe...@gmail.com] Sent: Tuesday, October 22, 2013 11:45 AM To: Artem Dmytrenko; yong sheng gong (gong...@unitedstack.com); OpenStack Development Mailing List; Vasudevan, Swaminathan (PNB Roseville) Subject: Re: Re: [openstack-dev] [Neutron] Distributed Virtual Router Discussion Hi Artem, Very happy to see more stackers working on this feature. : ) Note that the images in your document are badly corrupted - maybe my questions could already be answered by your diagrams. I met the same issue at first. Downloading the doc and open it locally may help. It works for me. Also, a wiki page for DVR/VDR feature is created, including some interesting performance test output. Thanks. https://wiki.openstack.org/wiki/Distributed_Router_for_OVS Best, Robin Wang From: Artem Dmytrenkomailto:nexton...@yahoo.com Date: 2013-10-22 02:51 To: yong sheng gong \(gong...@unitedstack.com\)mailto:gong...@unitedstack.com; cloudbe...@gmail.commailto:cloudbe...@gmail.com; OpenStack Development Mailing Listmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Distributed Virtual Router Discussion Hi Swaminathan. I work for a virtual networking startup called Midokura and I'm very interested in joining the discussion. We currently have distributed router implementation using existing Neutron API. Could you clarify why distributed vs centrally located routing implementation need to be distinguished? Another question is that are you proposing distributed routing implementation for tenant routers or for the router connecting the virtual cloud to the external network? The reason that I'm asking this question is because our company would also like to propose a router implementation that would eliminate a single point uplink failures. We have submitted a couple blueprints on that topic (https://blueprints.launchpad.net/neutron/+spec/provider-router-support, https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing) and would appreciate an opportunity to collaborate on making it a reality. Note that the images in your document are badly corrupted - maybe my questions could already be answered by your diagrams. Could you update your document with legible diagrams? Looking forward to further discussing this topic with you! Sincerely, Artem Dmytrenko On Mon, 10/21/13, Vasudevan, Swaminathan (PNB Roseville) swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.com wrote: Subject: [openstack-dev] Distributed Virtual Router Discussion To: yong sheng gong (gong...@unitedstack.commailto:gong...@unitedstack.com) gong...@unitedstack.commailto:gong...@unitedstack.com, cloudbe...@gmail.commailto:cloudbe...@gmail.com cloudbe...@gmail.commailto:cloudbe...@gmail.com, OpenStack Development Mailing List (openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, October 21, 2013, 12:18 PM Hi Folks, I am currently working on a blueprint for Distributed Virtual Router. If anyone interested in being part of the discussion please let me know. I have put together a first draft of my blueprint and have posted it on Launchpad for review. https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr 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 -Inline Attachment Follows- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Gerrit tools
Sure I'll look it over :-) Btw just uploaded: https://pypi.python.org/pypi/gerrit-view Making it easier to install the 2 tools. Have fun! On 10/21/13 11:37 PM, Flavio Percoco fla...@redhat.com wrote: On 21/10/13 15:55 +, Joshua Harlow wrote: I am using gerritlib in the curses ui; seems to work nicely. Only 1 thing that I don't like so much is that it silences connection/other errors from what I can tell. See _run() method in https://github.com/openstack-infra/gerritlib/blob/master/gerritlib/gerrit .py I started migrating some of the OpenStack tools to python-gerrit a couple of months ago, I still have that code somewhere in my laptop, I hope. I think that gerritlib API could be improved a lot from python-gerrit, plus query combinations in gerritlib are a bit limited due to how they're expressed there. At least the last time I checked. I'll take some time in the next few weeks to work on that. @Joshua, do you mind taking a look at python-gerrit and provide some feedback or use it? :D Cheers, FF Otherwise pretty easy to use. Sent from my really tiny device... On Oct 21, 2013, at 4:46 AM, Sean Dague s...@dague.net wrote: On 10/21/2013 04:04 AM, Flavio Percoco wrote: On 20/10/13 05:01 +, Joshua Harlow wrote: I created some gerrit tools that I think others might find useful. https://github.com/harlowja/gerrit_view I worked on this Python library for Gerrit[0] a couple of months ago and I've been using it for this gerrit-cli[1] tool. I was wondering if you'd like to migrate your Gerrit queries and make them use python-gerrit instead? I can do that for you. [0] https://github.com/FlaPer87/python-gerrit [1] https://github.com/FlaPer87/gerrit-cli BTW, Big +1 for the curses UI! Also realize that OpenStack maintains gerritlib - https://github.com/openstack-infra/gerritlib Which anyone can contribute to (and is the code that every message posted back to gerrit by a bot users). It would actually be nice to enhance gerritlib if there were enough features missing that are in python-gerrit. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- @flaper87 Flavio Percoco ___ 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] [Heat] HOT Software configuration proposal
Stan Lagun sla...@mirantis.com wrote on 22.10.2013 19:02:38:
From: Stan Lagun sla...@mirantis.com
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org,
Date: 22.10.2013 19:06
Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
Hello,
I've been reading through the thread and the wiki pages and I'm
still confused by the terms. Is there a clear definition of what do
we understand by component from user's and developer's point of
view. If I write component, type:MySQL what is behind that
definition? I mean how does the system know what exactly MySQL is
I think the current proposal is not that Heat would support very specific
component types (like MySQL, Apache, Tomcat etc.) but component is more of
a generic construct to represent a piece of software. The type attribute of
a component then just calls out the config management tool (e.g. Chef) to
install and configure that piece of software. By pointing a component to,
say, a Chef cookbook for setting up MySQL the runtime type would be MySQL.
That is at least my view on this.
I agree, however, that it needs to be straightened out how the term
component is really used.
and how to install it? What MySQL version is it gonna be? Will it be
x86 or x64? How does the system understand that I need MySQL for
Windows on Windows VM rather then Linux MySQL? What do I as a
developer need to do so that it would be possible to have type:
MyCoolComponentType?
On Tue, Oct 22, 2013 at 8:35 PM, Thomas Spatzier
thomas.spatz...@de.ibm.com
wrote:
Zane Bitter zbit...@redhat.com wrote on 22.10.2013 17:23:52:
From: Zane Bitter zbit...@redhat.com
To: openstack-dev@lists.openstack.org,
Date: 22.10.2013 17:26
Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
On 22/10/13 16:35, Thomas Spatzier wrote:
Zane Bitter zbit...@redhat.com wrote on 22.10.2013 15:24:28:
From: Zane Bitter zbit...@redhat.com
To: openstack-dev@lists.openstack.org,
Date: 22.10.2013 15:27
Subject: Re: [openstack-dev] [Heat] HOT Software configuration
proposal
On 22/10/13 09:15, Thomas Spatzier wrote:
BTW, the convention of properties being input and attributes being
output,
i.e. that subtle distinction between properties and attributes is
not
really intuitive, at least not to me as non-native speaker, because
I
used
to use both words as synonyms.
As a native speaker, I can confidently state that it's not intuitive
to
anyone ;)
Phew, good to read that ;-)
We unfortunately inherited these names from the Properties section
and
the Fn::GetAtt function in cfn templates. It's even worse than that,
because there's a whole category of... uh... things (DependsOn,
DeletionPolicy, c.) that don't even have a name - I always have to
resist the urge to call them 'attributes' too.
So is this something we should try to get straight in HOT while we
still
have the flexibility?
Y-yes. Provided that we can do it without making things *more*
confusing, +1. That's hard though, because there are a number of places
we have to refer to them, all with different audiences:
- HOT users
- cfn users
- Existing developers
- New developers
- Plugin developers
and using different names for the same thing can cause problems. My
test
for this is: if you were helping a user on IRC debug an issue, is there
a high chance you would spend 15 minutes talking past each other
because
they misunderstand the terminology?
Hm, good point. Seems like it would really cause more confusion than it
helps. So back away from the general idea of renaming things that exist
both in cfn and HOT.
What we should try of course is to give new concepts that will only exist
in HOT intuitive names.
Regarding properties/attributes for example, to me I would call both
just
properties of a resource or component, and then I can write them or
read
them like:
components:
my_component:
type: ...
properties:
my_prop: { get_property: [ other_component,
other_component_prop ] }
other_component:
# ...
I.e. you write property 'my_prop' of 'my_component' in its properties
section, and you read property 'other_component_prop' of
'other_component'
using the get_property function.
... we can also call them attributes, but use one name, not two
different
names for the same thing.
IMO inputs (Properties) and outputs (Fn::GetAtt) are different things
(and they exist in different namespaces), so -1 for giving them the
same
name.
In an ideal world I'd like HOT to use something like get_output_data
(or
maybe just get_data), but OTOH we have e.g. FnGetAtt() and
attributes_schema baked in to the plugin API that we can't really
change, so it seems likely to lead to developers and users adopting
different terminology, or making things very difficult for new
developers, or
[openstack-dev] [Trove] Replication and Clustering API
We have drawn up a new spec for the clustering api which removes the concept of a /clusters path as well as the need for the /clustertypes path. The spec lives here now: https://wiki.openstack.org/wiki/Trove-Replication-And-Clustering-API Initially I'd like to get eyes on this and see if we can't generate some discussion. This proposal is far reaching and will ultimately require a major versioning of the trove API to support. It is an amalgam of ideas from Vipul, hub_cap and a few others but we feel like this gets us much closer to having a more intuitive interface for users. Please peruse the document and lets start working through any issues. I would like to discuss the API proposal tomorrow during our weekly meeting but I would welcome comments/concerns on the mailing list as well. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] EC2 Compatibility metadata on config drive, fixed IP info
Hi, We are looking at config drive use cases, and saw this in the official docs: Do not rely on the presence of the EC2 metadata present in the config drive (i.e., files under the ec2 directory), as this content may be removed in a future release. http://docs.openstack.org/user-guide/content/config-drive.html Do we have any information on when will that EC2 metadata be dropped? I would like to get the fixed ip from the metadata, and I only found it in the EC2 section. Are there any plans to include the IP info in the OS metadata? Thanks, Mate -- Mate Lakat ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [savanna] What's the recipe to build Oozie-4.0.0.tar.gz?
Having diskimage-create.sh is a great addition for the Savanna user community. It greatly simplifies the image building process (using DIB for those of you not familiar), making it repeatable and giving everyone a hope of debugging issues. One thing it does is install oozie. It pulls oozie from http://savanna-files.mirantis.com/oozie-4.0.0.tar.gz What's the recipe to create oozie-4.0.0.tar.gz? Best, matt ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Glance] Summit proposal deadline
Hi folks, Please submit any design summit session proposals in the next 24 hours. markwash ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra] Meeting Tuesday October 22nd at 19:00 UTC
On Mon, Oct 21, 2013 at 4:20 PM, Elizabeth Krumbach Joseph l...@princessleia.com wrote: The OpenStack Infrastructure (Infra) team is hosting our weekly meeting tomorrow, Tuesday October 22nd, at 19:00 UTC in #openstack-meeting Thanks to everyone who attended, meeting minutes and logs here: Minutes: http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-10-22-19.01.html Minutes (text): http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-10-22-19.01.txt Log: http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-10-22-19.01.log.html -- Elizabeth Krumbach Joseph || Lyz || pleia2 http://www.princessleia.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [reviewstats] approved patches no longer count towards open reviews
Russell instant-fixed an issue we found in the TripleO meeting this morning: a patch ( https://review.openstack.org/#/c/52236/ ) was approved but stalled waiting on a dependency to get fixed and land. We noticed that patch because it was in the list of 'oldest patches', but it was entirely non-actionable :). Now, such patches are not listed at all, and won't contribute to the statistics for open reviews. This makes sense because their status isn't a reflection on the project at all : the submitter could rebase the patch (if it's not a real dependency), or if it is a real dependency, the dependency status will reflect appropriately (how long it's been open, has it got reviews etc). Anyhow, this is just a) thanks Russell! and b) a headsup if you notice an old review but your stats are better - this is why - approved reviews are not 'open'. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] meeting minutes
09:01 @openstack Meeting ended Tue Oct 22 20:01:03 2013 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 09:01 @openstack Minutes: http://eavesdrop.openstack.org/meetings/tripleo/2013/tripleo.2013-10-22-19.01.html 09:01 @openstack Minutes (text): http://eavesdrop.openstack.org/meetings/tripleo/2013/tripleo.2013-10-22-19.01.txt 09:01 @openstack Log: http://eavesdrop.openstack.org/meetings/tripleo/2013/tripleo.2013-10-22-19.01.log.html Thanks everyone for coming. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Distributed Virtual Router Discussion
Count me in on this discussion as well. May make sense to have a lightning talk at the summit, or an unconference slot. On Oct 22, 2013, at 1:50 PM, Vasudevan, Swaminathan (PNB Roseville) swaminathan.vasude...@hp.com wrote: Hi Folks, Thanks for your interests in the DVR feature. We should get together to start discussing the details in the DVR. Please let me know who else is interested, probably the time slot and we can start nailing down the details. https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr https://wiki.openstack.org/wiki/Distributed_Router_for_OVS Thanks Swami From: Robin Wang [mailto:cloudbe...@gmail.com] Sent: Tuesday, October 22, 2013 11:45 AM To: Artem Dmytrenko; yong sheng gong (gong...@unitedstack.com); OpenStack Development Mailing List; Vasudevan, Swaminathan (PNB Roseville) Subject: Re: Re: [openstack-dev] [Neutron] Distributed Virtual Router Discussion Hi Artem, Very happy to see more stackers working on this feature. : ) Note that the images in your document are badly corrupted - maybe my questions could already be answered by your diagrams. I met the same issue at first. Downloading the doc and open it locally may help. It works for me. Also, a wiki page for DVR/VDR feature is created, including some interesting performance test output. Thanks. https://wiki.openstack.org/wiki/Distributed_Router_for_OVS Best, Robin Wang From: Artem Dmytrenko Date: 2013-10-22 02:51 To: yong sheng gong \(gong...@unitedstack.com\); cloudbe...@gmail.com; OpenStack Development Mailing List Subject: Re: [openstack-dev] Distributed Virtual Router Discussion Hi Swaminathan. I work for a virtual networking startup called Midokura and I'm very interested in joining the discussion. We currently have distributed router implementation using existing Neutron API. Could you clarify why distributed vs centrally located routing implementation need to be distinguished? Another question is that are you proposing distributed routing implementation for tenant routers or for the router connecting the virtual cloud to the external network? The reason that I'm asking this question is because our company would also like to propose a router implementation that would eliminate a single point uplink failures. We have submitted a couple blueprints on that topic (https://blueprints.launchpad.net/neutron/+spec/provider-router-support, https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing) and would appreciate an opportunity to collaborate on making it a reality. Note that the images in your document are badly corrupted - maybe my questions could already be answered by your diagrams. Could you update your document with legible diagrams? Looking forward to further discussing this topic with you! Sincerely, Artem Dmytrenko On Mon, 10/21/13, Vasudevan, Swaminathan (PNB Roseville) swaminathan.vasude...@hp.com wrote: Subject: [openstack-dev] Distributed Virtual Router Discussion To: yong sheng gong (gong...@unitedstack.com) gong...@unitedstack.com, cloudbe...@gmail.com cloudbe...@gmail.com, OpenStack Development Mailing List (openstack-dev@lists.openstack.org) openstack-dev@lists.openstack.org Date: Monday, October 21, 2013, 12:18 PM Hi Folks, I am currently working on a blueprint for Distributed Virtual Router. If anyone interested in being part of the discussion please let me know. I have put together a first draft of my blueprint and have posted it on Launchpad for review. https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr 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.com -Inline Attachment Follows- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] HOT Software configuration proposal
Hi Thomas, I agree with you on semantics part. At the same time I see a potential question which might appear - if semantics is limited by few states visible for Heat engine, then who actually does software orchestration? Will it be reasonable then to have software orchestration as separate subproject for Heat as a part of Orchestration OpenStack program? Heat engine will then do dependency tracking and will use components as a reference for software orchestration engine which will perform actual deployment and high level software components coordination. This separated software orchestration engine may address all specific requirements proposed by different teams in this thread without affecting existing Heat engine. Thanks Georgy On Tue, Oct 22, 2013 at 12:06 PM, Thomas Spatzier thomas.spatz...@de.ibm.com wrote: Georgy Okrokvertskhov gokrokvertsk...@mirantis.com wrote on 22.10.2013 20:01:19: From: Georgy Okrokvertskhov gokrokvertsk...@mirantis.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org, Date: 22.10.2013 20:05 Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal Hi, I would agree with Stan that we need to discuss definitions before going deeply to the implementation. The first example on the https://wiki.openstack.org/wiki/Heat/ Blueprints/hot-software-config shows components like install_mysql and install_wordpress. Good point. I also think that at least the examples currently used are more of an automation step than a component. IMO component should represent some kind of software installation (e.g. a web server, a DBMS, etc.), where automation is used under the covers to install and configure that piece of software. From an orchestration point of view, a reasonable semantics would be that when a component is in state CREATE_COMPLETE it is ready to use, e.g. a web server is ready to serve applications. With respect to the automation that was used to bring up the component, it would return successful (and this would be signaled to Heat) when the component setup is done. For example, the following could represent an Apache web server component, installed using Chef: components: apache: type: OS::Heat::SoftwareConfig_Chef cookbook: http://www.example.com/my_apache_cookbook.zip properties: http_port: 8080 'apache' is just a name here that indicates of course what you get. The type indicates that a component provide able to invoke Chef automation is used. The cookbook attribute points to the cookbook to use, which will install and configure apache. By setting the http_port property to 8080, you provide input to the Chef cookbook. The SoftwareConfig_Chef component provider will implement the logic to pass properties to the Chef invocation in the right syntax. I would say that this is a bit confusing because I expected to see component definitions instead of software deployment definition process. I think this is a quite dangerous path here because this example shows us that we can use components as installation steps definition instead of real component definition. If one continue to do this approach and defines more and more granular steps as a components they will come to workflow definition composed in terms of components. This approach does not add either simplicity or clarity in the HOT template. Thanks Georgy On Tue, Oct 22, 2013 at 10:02 AM, Stan Lagun sla...@mirantis.com wrote: Hello, I've been reading through the thread and the wiki pages and I'm still confused by the terms. Is there a clear definition of what do we understand by component from user's and developer's point of view. If I write component, type:MySQL what is behind that definition? I mean how does the system know what exactly MySQL is and how to install it? What MySQL version is it gonna be? Will it be x86 or x64? How does the system understand that I need MySQL for Windows on Windows VM rather then Linux MySQL? What do I as a developer need to do so that it would be possible to have type: MyCoolComponentType? On Tue, Oct 22, 2013 at 8:35 PM, Thomas Spatzier thomas.spatz...@de.ibm.com wrote: Zane Bitter zbit...@redhat.com wrote on 22.10.2013 17:23:52: From: Zane Bitter zbit...@redhat.com To: openstack-dev@lists.openstack.org, Date: 22.10.2013 17:26 Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal On 22/10/13 16:35, Thomas Spatzier wrote: Zane Bitter zbit...@redhat.com wrote on 22.10.2013 15:24:28: From: Zane Bitter zbit...@redhat.com To: openstack-dev@lists.openstack.org, Date: 22.10.2013 15:27 Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal On 22/10/13 09:15, Thomas Spatzier wrote: BTW, the convention of properties being input and attributes being output, i.e. that subtle distinction between properties and attributes is not
[openstack-dev] [Neutron] FWaaS zone proposal - seeking feedback
Hi All, The Neutron FWaaS team would like to solicit your feedback on a proposal for supporting Zones as a part of firewall support. The common definition for zones involves the use of interfaces. In Neutron interfaces have a one-to-one correspondence with Neutron ports. The current proposal is to define zones based on Neutron ports. Source and destination zone arguments can be added to the firewall rule. Placeholder blueprint is available here: https://blueprints.launchpad.net/neutron/+spec/fwaas-zones-api We will discuss this in tomorrow's FWaaS IRC meeting. Please join. Thanks, ~Sumit. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] FWaaS IceHouse summit prep and IRC meeting
Reminder - we will have the Neutron FWaaS IRC meeting tomorrow Wednesday 18:00 UTC (11 AM PDT). Agenda: * Tempest tests * Definition and use of zones * Address Objects * Counts API * Service Objects * Integration with service type framework * Open discussion - any other topics you would like to bring up for discussion during the summit. https://wiki.openstack.org/wiki/Meetings/FWaaS Thanks, ~Sumit. On Sun, Oct 13, 2013 at 1:56 PM, Sumit Naiksatam sumitnaiksa...@gmail.comwrote: Hi All, For the next of phase of FWaaS development we will be considering a number of features. I am proposing an IRC meeting on Oct 16th Wednesday 18:00 UTC (11 AM PDT) to discuss this. The etherpad for the summit session proposal is here: https://etherpad.openstack.org/p/icehouse-neutron-fwaas and has a high level list of features under consideration. Thanks, ~Sumit. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Distributed Virtual Router Discussion
Count me in as well. On Tue, Oct 22, 2013 at 1:20 PM, Kyle Mestery (kmestery) kmest...@cisco.com wrote: Count me in on this discussion as well. May make sense to have a lightning talk at the summit, or an unconference slot. On Oct 22, 2013, at 1:50 PM, Vasudevan, Swaminathan (PNB Roseville) swaminathan.vasude...@hp.com wrote: Hi Folks, Thanks for your interests in the DVR feature. We should get together to start discussing the details in the DVR. Please let me know who else is interested, probably the time slot and we can start nailing down the details. https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr https://wiki.openstack.org/wiki/Distributed_Router_for_OVS Thanks Swami From: Robin Wang [mailto:cloudbe...@gmail.com] Sent: Tuesday, October 22, 2013 11:45 AM To: Artem Dmytrenko; yong sheng gong (gong...@unitedstack.com); OpenStack Development Mailing List; Vasudevan, Swaminathan (PNB Roseville) Subject: Re: Re: [openstack-dev] [Neutron] Distributed Virtual Router Discussion Hi Artem, Very happy to see more stackers working on this feature. : ) Note that the images in your document are badly corrupted - maybe my questions could already be answered by your diagrams. I met the same issue at first. Downloading the doc and open it locally may help. It works for me. Also, a wiki page for DVR/VDR feature is created, including some interesting performance test output. Thanks. https://wiki.openstack.org/wiki/Distributed_Router_for_OVS Best, Robin Wang From: Artem Dmytrenko Date: 2013-10-22 02:51 To: yong sheng gong \(gong...@unitedstack.com\); cloudbe...@gmail.com; OpenStack Development Mailing List Subject: Re: [openstack-dev] Distributed Virtual Router Discussion Hi Swaminathan. I work for a virtual networking startup called Midokura and I'm very interested in joining the discussion. We currently have distributed router implementation using existing Neutron API. Could you clarify why distributed vs centrally located routing implementation need to be distinguished? Another question is that are you proposing distributed routing implementation for tenant routers or for the router connecting the virtual cloud to the external network? The reason that I'm asking this question is because our company would also like to propose a router implementation that would eliminate a single point uplink failures. We have submitted a couple blueprints on that topic ( https://blueprints.launchpad.net/neutron/+spec/provider-router-support, https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing) and would appreciate an opportunity to collaborate on making it a reality. Note that the images in your document are badly corrupted - maybe my questions could already be answered by your diagrams. Could you update your document with legible diagrams? Looking forward to further discussing this topic with you! Sincerely, Artem Dmytrenko On Mon, 10/21/13, Vasudevan, Swaminathan (PNB Roseville) swaminathan.vasude...@hp.com wrote: Subject: [openstack-dev] Distributed Virtual Router Discussion To: yong sheng gong (gong...@unitedstack.com) gong...@unitedstack.com, cloudbe...@gmail.com cloudbe...@gmail.com, OpenStack Development Mailing List (openstack-dev@lists.openstack.org) openstack-dev@lists.openstack.org Date: Monday, October 21, 2013, 12:18 PM Hi Folks, I am currently working on a blueprint for Distributed Virtual Router. If anyone interested in being part of the discussion please let me know. I have put together a first draft of my blueprint and have posted it on Launchpad for review. https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr 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.com -Inline Attachment Follows- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ravi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Distributed Virtual Router Discussion
Swami, I would like to participate in discussions as well. Carl On Tue, Oct 22, 2013 at 12:50 PM, Vasudevan, Swaminathan (PNB Roseville) swaminathan.vasude...@hp.com wrote: Hi Folks, Thanks for your interests in the DVR feature. We should get together to start discussing the details in the DVR. Please let me know who else is interested, probably the time slot and we can start nailing down the details. https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr https://wiki.openstack.org/wiki/Distributed_Router_for_OVS Thanks Swami From: Robin Wang [mailto:cloudbe...@gmail.com] Sent: Tuesday, October 22, 2013 11:45 AM To: Artem Dmytrenko; yong sheng gong (gong...@unitedstack.com); OpenStack Development Mailing List; Vasudevan, Swaminathan (PNB Roseville) Subject: Re: Re: [openstack-dev] [Neutron] Distributed Virtual Router Discussion Hi Artem, Very happy to see more stackers working on this feature. : ) Note that the images in your document are badly corrupted - maybe my questions could already be answered by your diagrams. I met the same issue at first. Downloading the doc and open it locally may help. It works for me. Also, a wiki page for DVR/VDR feature is created, including some interesting performance test output. Thanks. https://wiki.openstack.org/wiki/Distributed_Router_for_OVS Best, Robin Wang From: Artem Dmytrenko Date: 2013-10-22 02:51 To: yong sheng gong \(gong...@unitedstack.com\); cloudbe...@gmail.com; OpenStack Development Mailing List Subject: Re: [openstack-dev] Distributed Virtual Router Discussion Hi Swaminathan. I work for a virtual networking startup called Midokura and I'm very interested in joining the discussion. We currently have distributed router implementation using existing Neutron API. Could you clarify why distributed vs centrally located routing implementation need to be distinguished? Another question is that are you proposing distributed routing implementation for tenant routers or for the router connecting the virtual cloud to the external network? The reason that I'm asking this question is because our company would also like to propose a router implementation that would eliminate a single point uplink failures. We have submitted a couple blueprints on that topic (https://blueprints.launchpad.net/neutron/+spec/provider-router-support, https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing) and would appreciate an opportunity to collaborate on making it a reality. Note that the images in your document are badly corrupted - maybe my questions could already be answered by your diagrams. Could you update your document with legible diagrams? Looking forward to further discussing this topic with you! Sincerely, Artem Dmytrenko On Mon, 10/21/13, Vasudevan, Swaminathan (PNB Roseville) swaminathan.vasude...@hp.com wrote: Subject: [openstack-dev] Distributed Virtual Router Discussion To: yong sheng gong (gong...@unitedstack.com) gong...@unitedstack.com, cloudbe...@gmail.com cloudbe...@gmail.com, OpenStack Development Mailing List (openstack-dev@lists.openstack.org) openstack-dev@lists.openstack.org Date: Monday, October 21, 2013, 12:18 PM Hi Folks, I am currently working on a blueprint for Distributed Virtual Router. If anyone interested in being part of the discussion please let me know. I have put together a first draft of my blueprint and have posted it on Launchpad for review. https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr 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.com -Inline Attachment Follows- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Incorporate Auditing Support / Usage Notifications
On 21/10/13 15:11 -1000, Angus Salkeld wrote:
Hi all
There has been some interest in Heat generating usage notifications
http://summit.openstack.org/cfp/details/87
so I thought I'd implement the blueprint:
https://blueprints.launchpad.net/heat/+spec/send-notification
I'd like to ask for suggestions on the content of the notifications.
I have added a section for Heat here (please tell me if this is the
wrong place): https://wiki.openstack.org/wiki/SystemUsageData
My plan was to generate the notification on each stack state change
so as the wiki page says:
orchestration.stack.{create,update,delete,suspend,resume}.{start,error,end}
start maps to IN_PROGRESS
end maps to COMPLETE
If you have any other needs of the notification please respond.
I have a WIP here: https://review.openstack.org/#/c/53239/
-Angus
Thanks
Angus
___
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] [Heat] HOT Software configuration proposal
Excerpts from Georgy Okrokvertskhov's message of 2013-10-22 13:32:40 -0700:
Hi Thomas,
I agree with you on semantics part. At the same time I see a potential
question which might appear - if semantics is limited by few states visible
for Heat engine, then who actually does software orchestration?
Will it be reasonable then to have software orchestration as separate
subproject for Heat as a part of Orchestration OpenStack program? Heat
engine will then do dependency tracking and will use components as a
reference for software orchestration engine which will perform actual
deployment and high level software components coordination.
This separated software orchestration engine may address all specific
requirements proposed by different teams in this thread without affecting
existing Heat engine.
I'm not sure I know what software orchestration is, but I will take a
stab at a succinct definition:
Coordination of software configuration across multiple hosts.
If that is what you mean, then I believe what you actually want is
workflow. And for that, we have the Mistral project which was recently
announced [1].
Use that and you will simply need to define your desired workflow and
feed it into Mistral using a Mistral Heat resource. We can create a
nice bootstrapping resource for Heat instances that shims the mistral
workflow execution agent into machines (or lets us use one already there
via custom images).
I can imagine it working something like this:
resources:
mistral_workflow_handle:
type: OS::Mistral::WorkflowHandle
web_server:
type: OS::Nova::Server
components:
mistral_agent:
component_type: mistral
params:
workflow_: {ref: mistral_workflow_handle}
mysql_server:
type: OS::Nova::Server
components:
mistral_agent:
component_type: mistral
params:
workflow_handle: {ref: mistral_workflow_handle}
mistral_workflow:
type: OS::Mistral::Workflow
properties:
handle: {ref: mistral_workflow_handle}
workflow_reference: mysql_webapp_workflow
params:
mysql_server: {ref: mysql_server}
webserver: {ref: web_server}
And then the workflow is just defined outside of the Heat template (ok
I'm sure somebody will want to embed it, but I prefer stronger
separation). Something like this gets uploaded as
mysql_webapp_workflow:
[ 'step1': 'install_stuff',
'step2': 'wait(step1)',
'step3': 'allocate_sql_user(server=%mysql_server%)'
'step4': 'credentials=wait_and_read(step3)'
'step5': 'write_config_file(server=%webserver%)' ]
Or maybe it is declared as a graph, or whatever, but it is not Heat's
problem how to do workflows, it just feeds the necessary data from
orchestration into the workflow engine. This also means you can use a
non OpenStack workflow engine without any problems.
I think after having talked about this, we should have workflow live in
its own program.. we can always combine them if we want to, but having a
clear line would mean keeping the interfaces clean.
[1] http://lists.openstack.org/pipermail/openstack-dev/2013-October/016605.html
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Trove] Replication and Clustering API
Hi, I don't see the replication type in the metadata replication contract. For example someone can use MySQL Galera cluster with synchronous replication + asynchronous replication master-slave for backup to remote site. MS SQL offers alwaysON availability groups clustering with pair of synchronous replication plus up to 3 nodes with asynchronous replication. Also there are some existing different mechanisms like data mirroring (synchronous or asynchronous) or log shipping. So my point is that when you say replication, it is not obvious which type of replication is used. Thanks Georgy On Tue, Oct 22, 2013 at 12:37 PM, Daniel Salinas imsplit...@gmail.comwrote: We have drawn up a new spec for the clustering api which removes the concept of a /clusters path as well as the need for the /clustertypes path. The spec lives here now: https://wiki.openstack.org/wiki/Trove-Replication-And-Clustering-API Initially I'd like to get eyes on this and see if we can't generate some discussion. This proposal is far reaching and will ultimately require a major versioning of the trove API to support. It is an amalgam of ideas from Vipul, hub_cap and a few others but we feel like this gets us much closer to having a more intuitive interface for users. Please peruse the document and lets start working through any issues. I would like to discuss the API proposal tomorrow during our weekly meeting but I would welcome comments/concerns on the mailing list as well. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Georgy Okrokvertskhov Technical Program Manager, Cloud and Infrastructure Services, Mirantis http://www.mirantis.com Tel. +1 650 963 9828 Mob. +1 650 996 3284 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)
On Oct 22, 2013, at 10:35 AM, Michael Basnight wrote: Top posting cuz im a baller. We will get this fixed today. PS clint i like the way you think ;) https://review.openstack.org/#/c/53176/ Now that this is merged, and there is no stable/havana for clients, Ive got a question. What do the package maintainers use for clients? the largest versioned tag? If so i can push a new version of the client for packaging. signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Openstack on power pc/Freescale linux
All, I'm wondering if anyone tried OpenStack on Power PC/ free scale Linux? Thanks, Qing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Openstack on power pc/Freescale linux
We run openstack on ppc64 with RHEL 6.4 using the powervm nova virt driver. What do you want to know? Thanks, MATT RIEDEMANN Advisory Software Engineer Cloud Solutions and OpenStack Development Phone: 1-507-253-7622 | Mobile: 1-507-990-1889 E-mail: mrie...@us.ibm.com 3605 Hwy 52 N Rochester, MN 55901-1407 United States From: Qing He qing...@radisys.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org, Date: 10/22/2013 05:49 PM Subject:[openstack-dev] [nova] Openstack on power pc/Freescale linux All, I'm wondering if anyone tried OpenStack on Power PC/ free scale Linux? Thanks, Qing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev image/gif___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] EC2 Compatibility metadata on config drive, fixed IP info
On Wed, Oct 23, 2013 at 6:48 AM, Mate Lakat mate.la...@citrix.com wrote: Hi, We are looking at config drive use cases, and saw this in the official docs: Do not rely on the presence of the EC2 metadata present in the config drive (i.e., files under the ec2 directory), as this content may be removed in a future release. Huh. That's news to me. I wonder why we'd bother implementing it if we don't want people to use it? http://docs.openstack.org/user-guide/content/config-drive.html Do we have any information on when will that EC2 metadata be dropped? I would like to get the fixed ip from the metadata, and I only found it in the EC2 section. Are there any plans to include the IP info in the OS metadata? It shouldn't be hard to do... Can you file a bug to track it and let me know the bug id? Thanks, Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] HOT Software configuration proposal
Sounds like taskflow could be that program (+1 from me, ha)?
Mistral to me is a nice authenticated REST api + other goodies ontop of
something that reliably executes workflows.
But then what I described is also the majority of what openstack does
(authenticated REST api + other goodies ontop of VM/volume/network/...
workflows).
On 10/22/13 3:28 PM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Georgy Okrokvertskhov's message of 2013-10-22 13:32:40
-0700:
Hi Thomas,
I agree with you on semantics part. At the same time I see a potential
question which might appear - if semantics is limited by few states
visible
for Heat engine, then who actually does software orchestration?
Will it be reasonable then to have software orchestration as separate
subproject for Heat as a part of Orchestration OpenStack program? Heat
engine will then do dependency tracking and will use components as a
reference for software orchestration engine which will perform actual
deployment and high level software components coordination.
This separated software orchestration engine may address all specific
requirements proposed by different teams in this thread without
affecting
existing Heat engine.
I'm not sure I know what software orchestration is, but I will take a
stab at a succinct definition:
Coordination of software configuration across multiple hosts.
If that is what you mean, then I believe what you actually want is
workflow. And for that, we have the Mistral project which was recently
announced [1].
Use that and you will simply need to define your desired workflow and
feed it into Mistral using a Mistral Heat resource. We can create a
nice bootstrapping resource for Heat instances that shims the mistral
workflow execution agent into machines (or lets us use one already there
via custom images).
I can imagine it working something like this:
resources:
mistral_workflow_handle:
type: OS::Mistral::WorkflowHandle
web_server:
type: OS::Nova::Server
components:
mistral_agent:
component_type: mistral
params:
workflow_: {ref: mistral_workflow_handle}
mysql_server:
type: OS::Nova::Server
components:
mistral_agent:
component_type: mistral
params:
workflow_handle: {ref: mistral_workflow_handle}
mistral_workflow:
type: OS::Mistral::Workflow
properties:
handle: {ref: mistral_workflow_handle}
workflow_reference: mysql_webapp_workflow
params:
mysql_server: {ref: mysql_server}
webserver: {ref: web_server}
And then the workflow is just defined outside of the Heat template (ok
I'm sure somebody will want to embed it, but I prefer stronger
separation). Something like this gets uploaded as
mysql_webapp_workflow:
[ 'step1': 'install_stuff',
'step2': 'wait(step1)',
'step3': 'allocate_sql_user(server=%mysql_server%)'
'step4': 'credentials=wait_and_read(step3)'
'step5': 'write_config_file(server=%webserver%)' ]
Or maybe it is declared as a graph, or whatever, but it is not Heat's
problem how to do workflows, it just feeds the necessary data from
orchestration into the workflow engine. This also means you can use a
non OpenStack workflow engine without any problems.
I think after having talked about this, we should have workflow live in
its own program.. we can always combine them if we want to, but having a
clear line would mean keeping the interfaces clean.
[1]
http://lists.openstack.org/pipermail/openstack-dev/2013-October/016605.htm
l
___
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] [Heat] HOT Software configuration proposal
Hi Clint,
Thank you for the detailed analysis.
I'm not sure I know what software orchestration is, but I will take a
stab at a succinct definition:
Coordination of software configuration across multiple hosts.
Having this definition of software orchestration what will Heat
software orchestration component BP cover? I just trying to clarify for
myself what is Heat position and view on software orchestration based on
components and Heat view on workflows.
Right now it is not clear where is the separation line between component
and workflow. I think this blurred line introduced a lot of confusion in
this thread as some guys had a workflows based approach in mind and some
had component based view.
Thanks
Georgy
On Tue, Oct 22, 2013 at 3:28 PM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Georgy Okrokvertskhov's message of 2013-10-22 13:32:40 -0700:
Hi Thomas,
I agree with you on semantics part. At the same time I see a potential
question which might appear - if semantics is limited by few states
visible
for Heat engine, then who actually does software orchestration?
Will it be reasonable then to have software orchestration as separate
subproject for Heat as a part of Orchestration OpenStack program? Heat
engine will then do dependency tracking and will use components as a
reference for software orchestration engine which will perform actual
deployment and high level software components coordination.
This separated software orchestration engine may address all specific
requirements proposed by different teams in this thread without affecting
existing Heat engine.
I'm not sure I know what software orchestration is, but I will take a
stab at a succinct definition:
Coordination of software configuration across multiple hosts.
If that is what you mean, then I believe what you actually want is
workflow. And for that, we have the Mistral project which was recently
announced [1].
Use that and you will simply need to define your desired workflow and
feed it into Mistral using a Mistral Heat resource. We can create a
nice bootstrapping resource for Heat instances that shims the mistral
workflow execution agent into machines (or lets us use one already there
via custom images).
I can imagine it working something like this:
resources:
mistral_workflow_handle:
type: OS::Mistral::WorkflowHandle
web_server:
type: OS::Nova::Server
components:
mistral_agent:
component_type: mistral
params:
workflow_: {ref: mistral_workflow_handle}
mysql_server:
type: OS::Nova::Server
components:
mistral_agent:
component_type: mistral
params:
workflow_handle: {ref: mistral_workflow_handle}
mistral_workflow:
type: OS::Mistral::Workflow
properties:
handle: {ref: mistral_workflow_handle}
workflow_reference: mysql_webapp_workflow
params:
mysql_server: {ref: mysql_server}
webserver: {ref: web_server}
And then the workflow is just defined outside of the Heat template (ok
I'm sure somebody will want to embed it, but I prefer stronger
separation). Something like this gets uploaded as
mysql_webapp_workflow:
[ 'step1': 'install_stuff',
'step2': 'wait(step1)',
'step3': 'allocate_sql_user(server=%mysql_server%)'
'step4': 'credentials=wait_and_read(step3)'
'step5': 'write_config_file(server=%webserver%)' ]
Or maybe it is declared as a graph, or whatever, but it is not Heat's
problem how to do workflows, it just feeds the necessary data from
orchestration into the workflow engine. This also means you can use a
non OpenStack workflow engine without any problems.
I think after having talked about this, we should have workflow live in
its own program.. we can always combine them if we want to, but having a
clear line would mean keeping the interfaces clean.
[1]
http://lists.openstack.org/pipermail/openstack-dev/2013-October/016605.html
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Georgy Okrokvertskhov
Technical Program Manager,
Cloud and Infrastructure Services,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] HOT Software configuration proposal
Hi Joshua,
Sounds like taskflow could be that program (+1 from me, ha)?
Mistral to me is a nice authenticated REST api + other goodies ontop of
something that reliably executes workflows.
I would say that Mistral is a way to do this. My arguments are the
following:
1. Mistral decouples code. Heat can use API calls to invoke a workflows
execution instead of linking with taskflow library in the code. This is
standard SOA approach which OpenStack uses a lot.
2. Mistral will expose DSL to define tasks while taskflow will require
python code for task definition.
Mistral itself uses taskflow library to execute workflows but Mistral in
addition does parsing and translation from DSL task definition to actual
python code.
Heat can use taskflow for other purposes but workflows execution is not a
good reason for that. Just because of nature of workflows for deployment,
there is no knowledge about workflow until end user uploads it, so you can
not use taskflow itself and code this workflow in python without
preliminary knowledge about workflow.
If Heat uses just taskflow it should do all the work on workflow parsing
and translation to a code that Heat team wants to avoid. At least this is
my understanding.
Thanks
Georgy
On Tue, Oct 22, 2013 at 4:34 PM, Joshua Harlow harlo...@yahoo-inc.comwrote:
Sounds like taskflow could be that program (+1 from me, ha)?
Mistral to me is a nice authenticated REST api + other goodies ontop of
something that reliably executes workflows.
But then what I described is also the majority of what openstack does
(authenticated REST api + other goodies ontop of VM/volume/network/...
workflows).
On 10/22/13 3:28 PM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Georgy Okrokvertskhov's message of 2013-10-22 13:32:40
-0700:
Hi Thomas,
I agree with you on semantics part. At the same time I see a potential
question which might appear - if semantics is limited by few states
visible
for Heat engine, then who actually does software orchestration?
Will it be reasonable then to have software orchestration as separate
subproject for Heat as a part of Orchestration OpenStack program? Heat
engine will then do dependency tracking and will use components as a
reference for software orchestration engine which will perform actual
deployment and high level software components coordination.
This separated software orchestration engine may address all specific
requirements proposed by different teams in this thread without
affecting
existing Heat engine.
I'm not sure I know what software orchestration is, but I will take a
stab at a succinct definition:
Coordination of software configuration across multiple hosts.
If that is what you mean, then I believe what you actually want is
workflow. And for that, we have the Mistral project which was recently
announced [1].
Use that and you will simply need to define your desired workflow and
feed it into Mistral using a Mistral Heat resource. We can create a
nice bootstrapping resource for Heat instances that shims the mistral
workflow execution agent into machines (or lets us use one already there
via custom images).
I can imagine it working something like this:
resources:
mistral_workflow_handle:
type: OS::Mistral::WorkflowHandle
web_server:
type: OS::Nova::Server
components:
mistral_agent:
component_type: mistral
params:
workflow_: {ref: mistral_workflow_handle}
mysql_server:
type: OS::Nova::Server
components:
mistral_agent:
component_type: mistral
params:
workflow_handle: {ref: mistral_workflow_handle}
mistral_workflow:
type: OS::Mistral::Workflow
properties:
handle: {ref: mistral_workflow_handle}
workflow_reference: mysql_webapp_workflow
params:
mysql_server: {ref: mysql_server}
webserver: {ref: web_server}
And then the workflow is just defined outside of the Heat template (ok
I'm sure somebody will want to embed it, but I prefer stronger
separation). Something like this gets uploaded as
mysql_webapp_workflow:
[ 'step1': 'install_stuff',
'step2': 'wait(step1)',
'step3': 'allocate_sql_user(server=%mysql_server%)'
'step4': 'credentials=wait_and_read(step3)'
'step5': 'write_config_file(server=%webserver%)' ]
Or maybe it is declared as a graph, or whatever, but it is not Heat's
problem how to do workflows, it just feeds the necessary data from
orchestration into the workflow engine. This also means you can use a
non OpenStack workflow engine without any problems.
I think after having talked about this, we should have workflow live in
its own program.. we can always combine them if we want to, but having a
clear line would mean keeping the interfaces clean.
[1]
http://lists.openstack.org/pipermail/openstack-dev/2013-October/016605.htm
l
___
Re: [openstack-dev] [Heat] HOT Software configuration proposal
Ah,
Seems like a reasonable approach then :-)
I guess then heat is mainly doing top-level orchestration, and then mistral
does the workflow middle-level, and taskflow is (hopefully) at the
lowest-level??
Thanks Georgy!
From: Georgy Okrokvertskhov
gokrokvertsk...@mirantis.commailto:gokrokvertsk...@mirantis.com
Reply-To: OpenStack Development Mailing List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, October 22, 2013 4:53 PM
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
Hi Joshua,
Sounds like taskflow could be that program (+1 from me, ha)?
Mistral to me is a nice authenticated REST api + other goodies ontop of
something that reliably executes workflows.
I would say that Mistral is a way to do this. My arguments are the following:
1. Mistral decouples code. Heat can use API calls to invoke a workflows
execution instead of linking with taskflow library in the code. This is
standard SOA approach which OpenStack uses a lot.
2. Mistral will expose DSL to define tasks while taskflow will require python
code for task definition.
Mistral itself uses taskflow library to execute workflows but Mistral in
addition does parsing and translation from DSL task definition to actual python
code.
Heat can use taskflow for other purposes but workflows execution is not a good
reason for that. Just because of nature of workflows for deployment, there is
no knowledge about workflow until end user uploads it, so you can not use
taskflow itself and code this workflow in python without preliminary knowledge
about workflow.
If Heat uses just taskflow it should do all the work on workflow parsing and
translation to a code that Heat team wants to avoid. At least this is my
understanding.
Thanks
Georgy
On Tue, Oct 22, 2013 at 4:34 PM, Joshua Harlow
harlo...@yahoo-inc.commailto:harlo...@yahoo-inc.com wrote:
Sounds like taskflow could be that program (+1 from me, ha)?
Mistral to me is a nice authenticated REST api + other goodies ontop of
something that reliably executes workflows.
But then what I described is also the majority of what openstack does
(authenticated REST api + other goodies ontop of VM/volume/network/...
workflows).
On 10/22/13 3:28 PM, Clint Byrum cl...@fewbar.commailto:cl...@fewbar.com
wrote:
Excerpts from Georgy Okrokvertskhov's message of 2013-10-22 13:32:40
-0700:
Hi Thomas,
I agree with you on semantics part. At the same time I see a potential
question which might appear - if semantics is limited by few states
visible
for Heat engine, then who actually does software orchestration?
Will it be reasonable then to have software orchestration as separate
subproject for Heat as a part of Orchestration OpenStack program? Heat
engine will then do dependency tracking and will use components as a
reference for software orchestration engine which will perform actual
deployment and high level software components coordination.
This separated software orchestration engine may address all specific
requirements proposed by different teams in this thread without
affecting
existing Heat engine.
I'm not sure I know what software orchestration is, but I will take a
stab at a succinct definition:
Coordination of software configuration across multiple hosts.
If that is what you mean, then I believe what you actually want is
workflow. And for that, we have the Mistral project which was recently
announced [1].
Use that and you will simply need to define your desired workflow and
feed it into Mistral using a Mistral Heat resource. We can create a
nice bootstrapping resource for Heat instances that shims the mistral
workflow execution agent into machines (or lets us use one already there
via custom images).
I can imagine it working something like this:
resources:
mistral_workflow_handle:
type: OS::Mistral::WorkflowHandle
web_server:
type: OS::Nova::Server
components:
mistral_agent:
component_type: mistral
params:
workflow_: {ref: mistral_workflow_handle}
mysql_server:
type: OS::Nova::Server
components:
mistral_agent:
component_type: mistral
params:
workflow_handle: {ref: mistral_workflow_handle}
mistral_workflow:
type: OS::Mistral::Workflow
properties:
handle: {ref: mistral_workflow_handle}
workflow_reference: mysql_webapp_workflow
params:
mysql_server: {ref: mysql_server}
webserver: {ref: web_server}
And then the workflow is just defined outside of the Heat template (ok
I'm sure somebody will want to embed it, but I prefer stronger
separation). Something like this gets uploaded as
mysql_webapp_workflow:
[ 'step1': 'install_stuff',
'step2': 'wait(step1)',
'step3': 'allocate_sql_user(server=%mysql_server%)'
'step4': 'credentials=wait_and_read(step3)'
'step5':
Re: [openstack-dev] [Heat] HOT Software configuration proposal
Hi,
I guess then heat is mainly doing top-level orchestration, and then
mistral does the workflow middle-level, and taskflow is (hopefully) at the
lowest-level??
You drove the right picture. I can not say who is top-level and who is
low-level orchestration. This is all gear wheels which should work all
together well to achieve the result while Het is probably the driving wheel
among them who makes sure that everything is working.
Thanks
Georgy
On Tue, Oct 22, 2013 at 5:14 PM, Joshua Harlow harlo...@yahoo-inc.comwrote:
Ah,
Seems like a reasonable approach then :-)
I guess then heat is mainly doing top-level orchestration, and then
mistral does the workflow middle-level, and taskflow is (hopefully) at the
lowest-level??
Thanks Georgy!
From: Georgy Okrokvertskhov gokrokvertsk...@mirantis.com
Reply-To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Date: Tuesday, October 22, 2013 4:53 PM
To: OpenStack Development Mailing List openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
Hi Joshua,
Sounds like taskflow could be that program (+1 from me, ha)?
Mistral to me is a nice authenticated REST api + other goodies ontop of
something that reliably executes workflows.
I would say that Mistral is a way to do this. My arguments are the
following:
1. Mistral decouples code. Heat can use API calls to invoke a workflows
execution instead of linking with taskflow library in the code. This is
standard SOA approach which OpenStack uses a lot.
2. Mistral will expose DSL to define tasks while taskflow will require
python code for task definition.
Mistral itself uses taskflow library to execute workflows but Mistral in
addition does parsing and translation from DSL task definition to actual
python code.
Heat can use taskflow for other purposes but workflows execution is not
a good reason for that. Just because of nature of workflows for deployment,
there is no knowledge about workflow until end user uploads it, so you can
not use taskflow itself and code this workflow in python without
preliminary knowledge about workflow.
If Heat uses just taskflow it should do all the work on workflow parsing
and translation to a code that Heat team wants to avoid. At least this is
my understanding.
Thanks
Georgy
On Tue, Oct 22, 2013 at 4:34 PM, Joshua Harlow harlo...@yahoo-inc.comwrote:
Sounds like taskflow could be that program (+1 from me, ha)?
Mistral to me is a nice authenticated REST api + other goodies ontop of
something that reliably executes workflows.
But then what I described is also the majority of what openstack does
(authenticated REST api + other goodies ontop of VM/volume/network/...
workflows).
On 10/22/13 3:28 PM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Georgy Okrokvertskhov's message of 2013-10-22 13:32:40
-0700:
Hi Thomas,
I agree with you on semantics part. At the same time I see a potential
question which might appear - if semantics is limited by few states
visible
for Heat engine, then who actually does software orchestration?
Will it be reasonable then to have software orchestration as separate
subproject for Heat as a part of Orchestration OpenStack program?
Heat
engine will then do dependency tracking and will use components as a
reference for software orchestration engine which will perform actual
deployment and high level software components coordination.
This separated software orchestration engine may address all specific
requirements proposed by different teams in this thread without
affecting
existing Heat engine.
I'm not sure I know what software orchestration is, but I will take a
stab at a succinct definition:
Coordination of software configuration across multiple hosts.
If that is what you mean, then I believe what you actually want is
workflow. And for that, we have the Mistral project which was recently
announced [1].
Use that and you will simply need to define your desired workflow and
feed it into Mistral using a Mistral Heat resource. We can create a
nice bootstrapping resource for Heat instances that shims the mistral
workflow execution agent into machines (or lets us use one already there
via custom images).
I can imagine it working something like this:
resources:
mistral_workflow_handle:
type: OS::Mistral::WorkflowHandle
web_server:
type: OS::Nova::Server
components:
mistral_agent:
component_type: mistral
params:
workflow_: {ref: mistral_workflow_handle}
mysql_server:
type: OS::Nova::Server
components:
mistral_agent:
component_type: mistral
params:
workflow_handle: {ref: mistral_workflow_handle}
mistral_workflow:
type: OS::Mistral::Workflow
properties:
handle: {ref: mistral_workflow_handle}
workflow_reference: mysql_webapp_workflow
Re: [openstack-dev] [nova] Openstack on power pc/Freescale linux
Thanks Matt. I'd like know if anyone has tried to run the controller, API server and MySql database, msg queue, etc-the brain of the openstack, on ppc. Qing From: Matt Riedemann [mailto:mrie...@us.ibm.com] Sent: Tuesday, October 22, 2013 4:17 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [nova] Openstack on power pc/Freescale linux We run openstack on ppc64 with RHEL 6.4 using the powervm nova virt driver. What do you want to know? Thanks, MATT RIEDEMANN Advisory Software Engineer Cloud Solutions and OpenStack Development Phone: 1-507-253-7622 | Mobile: 1-507-990-1889 E-mail: mrie...@us.ibm.commailto:mrie...@us.ibm.com [IBM] 3605 Hwy 52 N Rochester, MN 55901-1407 United States From:Qing He qing...@radisys.commailto:qing...@radisys.com To:OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, Date:10/22/2013 05:49 PM Subject:[openstack-dev] [nova] Openstack on power pc/Freescale linux All, I'm wondering if anyone tried OpenStack on Power PC/ free scale Linux? Thanks, Qing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev inline: image001.gif___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
