<div dir="ltr">unsubscribe</div><div class="gmail_extra"><br clear="all"><div>--Alok</div>
<br><br><div class="gmail_quote">On Fri, Nov 22, 2013 at 12:03 PM, <span dir="ltr"><<a href="mailto:openstack-dev-request@lists.openstack.org" target="_blank">openstack-dev-request@lists.openstack.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send OpenStack-dev mailing list submissions to<br>
<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:openstack-dev-request@lists.openstack.org">openstack-dev-request@lists.openstack.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:openstack-dev-owner@lists.openstack.org">openstack-dev-owner@lists.openstack.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of OpenStack-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: [horizon] Javascript development improvement (Matthias Runge)<br>
2. Re: [horizon] Javascript development improvement (Matthias Runge)<br>
3. Re: [Cinder][Glance] OSLO update (Elena Ezhova)<br>
4. Re: [nova][heat][[keystone] RFC: introducing "request<br>
identification" (Mitsuru Kanabuchi)<br>
5. Re: [nova] future fate of nova-network? (Soren Hansen)<br>
6. Re: [nova] future fate of nova-network? (Daniel P. Berrange)<br>
7. Re: [horizon] Javascript development improvement (Sascha Peilicke)<br>
8. Re: [horizon] Javascript development improvement (Maxime Vidori)<br>
9. Re: [nova] future fate of nova-network? (Sean Dague)<br>
10. Re: [horizon] Javascript development improvement (Matthias Runge)<br>
11. Re: [Neutron][LBaaS] Subteam meeting on Thursday, 21<br>
(Eugene Nikanorov)<br>
12. Re: How to stage client major releases in Gerrit? (Dolph Mathews)<br>
13. Re: [Oslo] Improving oslo-incubator update.py (Ben Nemec)<br>
14. Re: [horizon] Javascript development improvement (Imre Farkas)<br>
15. [Neutron][LBaaS] L7 rules design (Eugene Nikanorov)<br>
16. FreeBSD hypervisor (bhyve) driver (Rafa? Jaworowski)<br>
17. Re: FreeBSD hypervisor (bhyve) driver (Russell Bryant)<br>
18. Re: Introducing the new OpenStack service for Containers<br>
(Krishna Raman)<br>
19. Re: Introducing the new OpenStack service for Containers<br>
(Krishna Raman)<br>
20. Re: [Nova][Schduler] Volunteers wanted for a modest proposal<br>
for an external scheduler in our lifetime (Mike Spreitzer)<br>
21. Re: [nova] future fate of nova-network? (Jonathan Proulx)<br>
22. Re: [Cinder][Glance] OSLO update (Duncan Thomas)<br>
23. Re: [nova] future fate of nova-network? (Russell Bryant)<br>
24. Re: [Oslo] Improving oslo-incubator update.py (Duncan Thomas)<br>
25. Re: [nova] future fate of nova-network? (Daniel P. Berrange)<br>
26. [Solum] Working group on language packs (Clayton Coleman)<br>
27. Re: Introducing the new OpenStack service for Containers<br>
(Clint Byrum)<br>
28. Re: Introducing the new OpenStack service for Containers<br>
(Krishna Raman)<br>
29. Re: [nova] future fate of nova-network? (Mike Spreitzer)<br>
30. Re: [Nova][Schduler] Volunteers wanted for a modest proposal<br>
for an external scheduler in our lifetime (Khanh-Toan Tran)<br>
31. Re: [horizon] Javascript development improvement (Julie Pichon)<br>
32. Re: [Keystone][Oslo] Future of Key Distribution Server,<br>
Trusted Messaging (Jarret Raim)<br>
33. Re: [horizon] Javascript development improvement (Julie Pichon)<br>
34. Re: L3 advanced features blueprint mapping to IETF and IEEE<br>
standards (Carl Baldwin)<br>
35. Re: [Cinder][Glance] OSLO update (Doug Hellmann)<br>
36. Re: [nova] future fate of nova-network? (Tim Bell)<br>
37. Re: [Oslo] Improving oslo-incubator update.py (Doug Hellmann)<br>
38. Re: [Oslo] Improving oslo-incubator update.py (Doug Hellmann)<br>
39. Re: [Ceilometer] meaning of resource_id in a meter (Doug Hellmann)<br>
40. Re: [nova] future fate of nova-network? (Lorin Hochstein)<br>
41. Re: RFC: Potential to increase min required libvirt version<br>
to 0.9.11 ? (Daniel P. Berrange)<br>
42. Re: [nova] future fate of nova-network? (Daniel P. Berrange)<br>
43. Re: [horizon] Javascript development improvement (Jordan OMara)<br>
44. Re: Introducing the new OpenStack service for Containers<br>
(Eric Windisch)<br>
45. Re: [Keystone][Oslo] Future of Key Distribution Server,<br>
Trusted Messaging (Mark McLoughlin)<br>
46. Re: [Nova][Schduler] Volunteers wanted for a modest proposal<br>
for an external scheduler in our lifetime (Yathiraj Udupi (yudupi))<br>
47. [Ironic][Cinder] Attaching Cinder volumes to baremetal<br>
instance (Rohan Kanade)<br>
48. Re: Introducing the new OpenStack service for Containers<br>
(Krishna Raman)<br>
49. Re: [Nova] [Infra] Support for PCI Passthrough (Jeremy Stanley)<br>
50. Re: [horizon] Javascript development improvement (Maxime Vidori)<br>
51. Re: How to stage client major releases in Gerrit? (Jeremy Stanley)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 22 Nov 2013 13:13:29 +0100<br>
From: Matthias Runge <<a href="mailto:mrunge@redhat.com">mrunge@redhat.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [horizon] Javascript development<br>
improvement<br>
Message-ID: <<a href="mailto:528F4A69.40302@redhat.com">528F4A69.40302@redhat.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
On 11/21/2013 01:55 PM, Jiri Tomasek wrote:<br>
> Hi,<br>
<br>
><br>
> Regarding less, I don't really care what compiler we use as long as it<br>
> works. And if we need to provide uncompiled less for production, then<br>
> let's use Lesscpy.<br>
><br>
<br>
There is at least one bug open against Ubuntu[1], asking to install<br>
python-lesscpy as well, as customers "often" need to re-create or change<br>
stylesheets.<br>
<br>
This would imply nodejs in a production environment, when going back to<br>
less.<br>
<br>
Just naming the n word here, makes people bite, for whatever reason ;-)<br>
<br>
Matthias<br>
<br>
[1]<br>
<a href="https://bugs.launchpad.net/ubuntu/+source/openstack-dashboard/+bug/1071276" target="_blank">https://bugs.launchpad.net/ubuntu/+source/openstack-dashboard/+bug/1071276</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 22 Nov 2013 13:14:50 +0100<br>
From: Matthias Runge <<a href="mailto:mrunge@redhat.com">mrunge@redhat.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [horizon] Javascript development<br>
improvement<br>
Message-ID: <<a href="mailto:528F4ABA.1080109@redhat.com">528F4ABA.1080109@redhat.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
On 11/22/2013 11:10 AM, Maxime Vidori wrote:<br>
> I will start reading documentation in order to integrate node in development, we also want to integrate its testing into the existing ones. I think a blueprint will be necessary.<br>
><br>
Since it was such a pain to get rid of nodejs, I'd love to see other<br>
options here.<br>
<br>
Matthias<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 22 Nov 2013 16:27:17 +0400<br>
From: Elena Ezhova <<a href="mailto:eezhova@mirantis.com">eezhova@mirantis.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [Cinder][Glance] OSLO update<br>
Message-ID:<br>
<<a href="mailto:CAFZxAhgXrF1iEf_3wAOrQB2WX3aK5PcA0jCyD0MhVPSHOr2M5g@mail.gmail.com">CAFZxAhgXrF1iEf_3wAOrQB2WX3aK5PcA0jCyD0MhVPSHOr2M5g@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
But what if I want to update some module that consists of ten or even more<br>
files (like rpc or db) and each of these files has quite a long change log?<br>
In that case the commit message may turn out to be really long even if only<br>
commit ids and names are included.<br>
<br>
<br>
On Wed, Nov 20, 2013 at 12:37 PM, Elena Ezhova <<a href="mailto:eezhova@mirantis.com">eezhova@mirantis.com</a>> wrote:<br>
<br>
><br>
> 20.11.2013, 06:18, "John Griffith" <<a href="mailto:john.griffith@solidfire.com">john.griffith@solidfire.com</a>>:<br>
><br>
> On Mon, Nov 18, 2013 at 3:53 PM, Mark McLoughlin <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>><br>
> wrote:<br>
><br>
> > On Mon, 2013-11-18 at 17:24 +0000, Duncan Thomas wrote:<br>
> >> Random OSLO updates with no list of what changed, what got fixed etc<br>
> >> are unlikely to get review attention - doing such a review is<br>
> >> extremely difficult. I was -2ing them and asking for more info, but<br>
> >> they keep popping up. I'm really not sure what the best way of<br>
> >> updating from OSLO is, but this isn't it.<br>
> > Best practice is to include a list of changes being synced, for example:<br>
> ><br>
> > <a href="https://review.openstack.org/54660" target="_blank">https://review.openstack.org/54660</a><br>
> ><br>
> > Every so often, we throw around ideas for automating the generation of<br>
> > this changes list - e.g. cinder would have the oslo-incubator commit ID<br>
> > for each module stored in a file in git to tell us when it was last<br>
> > synced.<br>
> ><br>
> > Mark.<br>
> ><br>
> > _____________________________<br>
>><br>
>> __________________<br>
>> > OpenStack-dev mailing list<br>
>> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>> Been away on vacation so I'm afraid I'm a bit late on this... but;<br>
>><br>
>> I think the point Duncan is bringing up here is that there are some<br>
>> VERY large and significant patches coming from OSLO pulls. The DB<br>
>> patch in particular being over 1K lines of code to a critical portion<br>
>> of the code is a bit unnerving to try and do a review on. I realize<br>
>> that there's a level of trust that goes with the work that's done in<br>
>> OSLO and synchronizing those changes across the projects, but I think<br>
>> a few key concerns here are:<br>
>><br>
>> 1. Doing huge pulls from OSLO like the DB patch here are nearly<br>
>> impossible to thoroughly review and test. Over time we learn a lot<br>
>> about real usage scenarios and the database and tweak things as we go,<br>
>> so seeing a patch set like this show up is always a bit unnerving and<br>
>> frankly nobody is overly excited to review it.<br>
>><br>
>> 2. Given a certain level of *trust* for the work that folks do on the<br>
>> OSLO side in submitting these patches and new additions, I think some<br>
>> of the responsibility on the review of the code falls on the OSLO<br>
>> team. That being said there is still the issue of how these changes<br>
>> will impact projects *other* than Nova which I think is sometimes<br>
>> neglected. There have been a number of OSLO synchs pushed to Cinder<br>
>> that fail gating jobs, some get fixed, some get abandoned, but in<br>
>> either case it shows that there wasn't any testing done with projects<br>
>> other than Nova (PLEASE note, I'm not referring to this particular<br>
>> round of patches or calling any patch set out, just stating a<br>
>> historical fact).<br>
>><br>
>> 3. We need better documentation in commit messages explaining why the<br>
>> changes are necessary and what they do for us. I'm sorry but in my<br>
>> opinion the answer "it's the latest in OSLO and Nova already has it"<br>
>> is not enough of an answer in my opinion. The patches mentioned in<br>
>> this thread in my opinion met the minimum requirements because they at<br>
>> least reference the OSLO commit which is great. In addition I'd like<br>
>> to see something to address any discovered issues or testing done with<br>
>> the specific projects these changes are being synced to.<br>
>><br>
>> I'm in no way saying I don't want Cinder to play nice with the common<br>
>> code or to get in line with the way other projects do things but I am<br>
>> saying that I think we have a ways to go in terms of better<br>
>> communication here and in terms of OSLO code actually keeping in mind<br>
>> the entire OpenStack eco-system as opposed to just changes that were<br>
>> needed/updated in Nova. Cinder in particular went through some pretty<br>
>> massive DB re-factoring and changes during Havana and there was a lot<br>
>> of really good work there but it didn't come without a cost and the<br>
>> benefits were examined and weighed pretty heavily. I also think that<br>
>> some times the indirection introduced by adding some of the<br>
>> openstack.common code is unnecessary and in some cases makes things<br>
>> more difficult than they should be.<br>
>><br>
>> I'm just not sure that we always do a very good ROI investigation or<br>
>> risk assessment on changes, and that opinion applies to ALL changes in<br>
>> OpenStack projects, not OSLO specific or anything else.<br>
>><br>
>> All of that being said, a couple of those syncs on the list are<br>
>> outdated. We should start by doing a fresh pull for these and if<br>
>> possible add some better documentation in the commit messages as to<br>
>> the justification for the patches that would be great. We can take a<br>
>> closer look at the changes and the history behind them and try to get<br>
>> some review progress made here. Mark mentioned some good ideas<br>
>> regarding capturing commit ID's from synchronization pulls and I'd<br>
>> like to look into that a bit as well.<br>
>><br>
>> Thanks,<br>
>> John<br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> I see now that updating OSLO is a far more complex issue than it may seem<br>
> from the first sight.<br>
> But I would really like to do my best to make it look acceptable and<br>
> possible to review.<br>
><br>
> It seems everybody agrees that commit messages should have change logs of<br>
> the updated files.<br>
> It can be done by writing a shell script that will generate this logs by<br>
> simply executing a git log command.<br>
> But the problem is how to get the initial version of the file that is<br>
> being updated.<br>
><br>
> As Mark McLoughlin said, it may be a good idea to store OSLO commit-ids<br>
> for each module in some file.<br>
> This file will have to be changed every time an update is performed which<br>
> implies changing update.py<br>
> in oslo-incubator. The the shell script will just have to fetch a<br>
> change-id from this file.<br>
><br>
> I will try to write the script and generate logs, but I'm not sure about<br>
> how can I put all these logs in<br>
> a commit message because one patch usually changes more than one file and<br>
> each file may have<br>
> quite a long log.<br>
><br>
> So I would really appreciate any comments or pieces of advice.<br>
><br>
> Thanks,<br>
> Elena<br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/9c60c258/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/9c60c258/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Fri, 22 Nov 2013 21:30:20 +0900<br>
From: Mitsuru Kanabuchi <<a href="mailto:kanabuchi.mitsuru@po.ntts.co.jp">kanabuchi.mitsuru@po.ntts.co.jp</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [nova][heat][[keystone] RFC: introducing<br>
"request identification"<br>
Message-ID: <<a href="mailto:20131122213020.8b80d3a0acf30ad7f452916f@po.ntts.co.jp">20131122213020.8b80d3a0acf30ad7f452916f@po.ntts.co.jp</a>><br>
Content-Type: text/plain; charset=US-ASCII<br>
<br>
<br>
On Tue, 19 Nov 2013 12:03:57 -0500<br>
Adam Young <<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>> wrote:<br>
<br>
> On 11/19/2013 08:21 AM, Dolph Mathews wrote:<br>
> > Related BP:<br>
> ><br>
> > Create a unified request identifier<br>
> > <a href="https://blueprints.launchpad.net/nova/+spec/cross-service-request-id" target="_blank">https://blueprints.launchpad.net/nova/+spec/cross-service-request-id</a><br>
<br>
I interested in cross-service-request-id because it has potential to<br>
solve several problem.<br>
<br>
I believe that API-retry would improve reliability of processing<br>
especially in HA environment.<br>
But it has fundamental problem what POST methods isn't idempotent.<br>
In my understand, currently, a lot of OpenStack API caller doesn't<br>
API-retry to avoid problem when do POST and response was lost.<br>
<br>
For reference:<br>
<a href="https://wiki.openstack.org/wiki/Support-retry-with-idempotency" target="_blank">https://wiki.openstack.org/wiki/Support-retry-with-idempotency</a><br>
<br>
I think id has to be something passed in by the client is essential<br>
part of to solve that problem.<br>
And I recently found that cross-service-request-id could realize<br>
that objective. It is really nice idea.<br>
<br>
I understand, currently cross-service-request-id's objective is for<br>
debugging. It is very useful.<br>
In addition, I think that cross-service-request-id can use for<br>
ensuring POST idempotent.<br>
If the service received known cross-service-request-id, the service<br>
just return existence resource-id to clients.<br>
And the service don't create new resource.<br>
<br>
I understand it's need several considerations.<br>
(Please refer the thread of<br>
[Heat]Updated summit etherpad: API-retry-with-idempotency)<br>
<br>
However, basically it's good function for reliability.<br>
What do you think about it?<br>
<br>
<br>
> And we have discussed workplans as well, which would be data to be<br>
> carried along with the request id<br>
><br>
> <a href="https://blueprints.launchpad.net/keystone/+spec/delegation-workplans" target="_blank">https://blueprints.launchpad.net/keystone/+spec/delegation-workplans</a><br>
> <a href="https://etherpad.openstack.org/keystone_workplans" target="_blank">https://etherpad.openstack.org/keystone_workplans</a><br>
><br>
> ><br>
> > On Tue, Nov 19, 2013 at 5:04 AM, haruka tanizawa <<a href="mailto:harubelle@gmail.com">harubelle@gmail.com</a><br>
> > <mailto:<a href="mailto:harubelle@gmail.com">harubelle@gmail.com</a>>> wrote:<br>
> ><br>
> > Hi stackers!!<br>
> ><br>
> > I'd like to ask for your opinions about my idea of identifying<br>
> > request.<br>
> ><br>
> > Challenges<br>
> > ==========<br>
> ><br>
> > We have no way to know the final result of an API request.<br>
> > Indeed we can continuously get the status of allocated resources,<br>
> > but this is just resource status, not request status.<br>
> ><br>
> > It doesn't matter so much for manual operations.<br>
> > But it does for automated clients like heat.<br>
> > We need request-oriented-status and it should be disclosed to clients.<br>
> ><br>
> > Literally, we need to address two items for it.<br>
> > 1. how to identify request from clients<br>
> > 2. how to disclose status of request to clients<br>
> ><br>
> > Note that this email includes only 1 for initiating the discussion.<br>
> > Also, bp:instance-tasks-api[0] should include both two items above.<br>
> ><br>
> > Proposal: introducing "request identification"<br>
> > =============================================<br>
> ><br>
> > I'd like to introduce "request identification", which is disclosed<br>
> > to clients.<br>
> > There are two characteristics:<br>
> ><br>
> > - "request identification" is unique ID for each request<br>
> > so that we can identify tell a specific request from others.<br>
> > - "request identification" is available for clients<br>
> > so that we can enable any after-request-operations like check,<br>
> > retry[1] or cancel[2].<br>
> > (of course we need to add more logic for check/retry/cancel,<br>
> > but I'm pretty sure that indentifying request is the starting<br>
> > point for these features)<br>
> ><br>
> > In my understandings, main objections should be 'who should<br>
> > generate and maintain such IDs?'.<br>
> ><br>
> > How to implement "request identification"<br>
> > =========================================<br>
> ><br>
> > There are several options at least. (See also recent discussion at<br>
> > openstack-dev[3])<br>
> ><br>
> > 1. Enable user to provide his/her own "request identification"<br>
> > within API request.<br>
> > This should be the simplest way. But providing id from outside<br>
> > looks hard to be accepted.<br>
> > For example, Idempotency for OpenStack API[4].<br>
> > Or instance-tasks-api enable to user to put his/her own<br>
> > "request identification".<br>
> ><br>
> > 2. Use correlation_id in oslo as "request identification".<br>
> > correlation_id looks similar concept of "request indentification",<br>
> > but correlation_id in nova was already rejected[5].<br>
> ><br>
> > 3. Enable keystone to generate "request identification" (we can<br>
> > call it 'request-token', for example).<br>
> > Before sending actual API request to nova-api, client sends a<br>
> > request to keystone to get 'request-token'.<br>
> ><br>
> ><br>
> > -2<br>
> ><br>
> > Then client sends an actual API request with 'request-token'.<br>
> > Nova-api will consult it to keystone whether it was really<br>
> > generated.<br>
> > Sounds like a auth-token generated by keystone, differences are:<br>
> > [lifecycle] auth-token is used for multiple API requests<br>
> > before it expires,<br>
> > 'request-token' is used for only single API request.<br>
> > [reusing] if the same 'request-token' was specified twice or<br>
> > more times,<br>
> > nova-api simply returns 20x (works like client token in<br>
> > AWS[6]).<br>
> > Keystone needs to maintain 'request-tokens' until they expire.<br>
> > For backward compatibility, actual API request without<br>
> > 'request-token' should work as before.<br>
> > We can consider several options for uniqueness of 'request-token':<br>
> > uuid, any string with uniqueness per tennant, etc.<br>
> ><br>
> > IMO, since adding new implementation to Keystone is a little bit<br>
> > hard work,<br>
> > so implement of 1 is reasonable for me, just idea.<br>
> ><br>
> > Any comments will be appreciated.<br>
> ><br>
> > Sincerely, Haruka Tanizawa<br>
> ><br>
> > [0] <a href="https://blueprints.launchpad.net/nova/+spec/instance-tasks-api" target="_blank">https://blueprints.launchpad.net/nova/+spec/instance-tasks-api</a><br>
> > [1] <a href="https://wiki.openstack.org/wiki/Support-retry-with-idempotency" target="_blank">https://wiki.openstack.org/wiki/Support-retry-with-idempotency</a><br>
> > [2] <a href="https://blueprints.launchpad.net/nova/+spec/cancel-swap-volume" target="_blank">https://blueprints.launchpad.net/nova/+spec/cancel-swap-volume</a><br>
> > [3]<br>
> > <a href="http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg09023.html" target="_blank">http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg09023.html</a><br>
> > [4]<br>
> > <a href="https://blueprints.launchpad.net/nova/+spec/idempotentcy-client-token" target="_blank">https://blueprints.launchpad.net/nova/+spec/idempotentcy-client-token</a><br>
> > [5] <a href="https://review.openstack.org/#/c/29480/" target="_blank">https://review.openstack.org/#/c/29480/</a><br>
> > [6]<br>
> > <a href="http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Run_Instance_Idempotency.html" target="_blank">http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Run_Instance_Idempotency.html</a><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> ><br>
> > -Dolph<br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
--------------------<br>
Mitsuru Kanabuchi<br>
NTT Software Corporation<br>
E-Mail : <a href="mailto:kanabuchi.mitsuru@po.ntts.co.jp">kanabuchi.mitsuru@po.ntts.co.jp</a><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Fri, 22 Nov 2013 13:36:12 +0100<br>
From: Soren Hansen <<a href="mailto:soren@linux2go.dk">soren@linux2go.dk</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [nova] future fate of nova-network?<br>
Message-ID:<br>
<<a href="mailto:CAPFUtkbro-o-xdB7u2dgctM4trvQE6uXAmQyN9AyACidYhywZQ@mail.gmail.com">CAPFUtkbro-o-xdB7u2dgctM4trvQE6uXAmQyN9AyACidYhywZQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
2013/11/22 John Garbutt <<a href="mailto:john@johngarbutt.com">john@johngarbutt.com</a>>:<br>
> Another approach to help with (1) is in Icehouse we remove the<br>
> features from nova-network that neutron does not implement. We have<br>
> warned about deprecation for a good few releases, so its almost OK.<br>
<br>
You want to motivate Neutron developers by punishing users of<br>
nova-network who are probably already nervous that the rug will be<br>
pulled out from under them? I'm about a -1,000,000 on that one.<br>
<br>
--<br>
Soren Hansen | <a href="http://linux2go.dk/" target="_blank">http://linux2go.dk/</a><br>
Ubuntu Developer | <a href="http://www.ubuntu.com/" target="_blank">http://www.ubuntu.com/</a><br>
OpenStack Developer | <a href="http://www.openstack.org/" target="_blank">http://www.openstack.org/</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Fri, 22 Nov 2013 12:47:19 +0000<br>
From: "Daniel P. Berrange" <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [nova] future fate of nova-network?<br>
Message-ID: <<a href="mailto:20131122124719.GD16339@redhat.com">20131122124719.GD16339@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
On Fri, Nov 22, 2013 at 11:25:51AM +0000, John Garbutt wrote:<br>
> >> On Fri, Nov 15, 2013 at 2:21 PM, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>> wrote:<br>
> >>>> In particular, has there been a decision made about whether it will<br>
> >>>> definitely be deprecated in some (as yet unspecified) future release, or<br>
> >>>> whether it will continue to be supported for the foreseeable future?<br>
> >>><br>
> >>> We want to deprecate it. There are some things blocking moving forward<br>
> >>> with this. In short:<br>
> >>><br>
> >>> 1) Feature parity (primarily something that satisfies performance and HA<br>
> >>> requirements addressed by nova-network in multi-host mode)<br>
> >>><br>
> >>> 2) Testing and quality parity. The status of Neutron testing in the<br>
> >>> gate is far inferior to the testing done against nova-network.<br>
> >>><br>
> >>> I'm personally more worried about #2 than #1 at this point.<br>
> >>><br>
> >>> A major issue is that very few people actually stepped up and agreed to<br>
> >>> help with #2 at the summit [2]. Only one person signed up to work on<br>
> >>> tempest issues. Nobody signed up to help with grenade. If this doesn't<br>
> >>> happen, nova-network can't be deprecated, IMO.<br>
> >>><br>
> >>> If significant progress isn't made ASAP this cycle, and ideally by<br>
> >>> mid-cycle so we can change directions if necessary, then we'll have to<br>
> >>> discuss what next step to take. That may include un-freezing<br>
> >>> nova-network so that various people holding on to enhancements to<br>
> >>> nova-network can start submitting them back. It's a last resort, but I<br>
> >>> consider it on the table.<br>
><br>
> Another approach to help with (1) is in Icehouse we remove the<br>
> features from nova-network that neutron does not implement. We have<br>
> warned about deprecation for a good few releases, so its almost OK.<br>
<br>
We deprecated it on the basis that users would be able to do a upgrade<br>
to new release providing something that was feature equivalent.<br>
<br>
We didn't deprecate it on the basis that we were going to remove the<br>
feature and provide no upgrade path, leaving users screwed.<br>
<br>
So I don't consider removing features from nova-network to be an<br>
acceptable approach, until they exist in Neutron or something else<br>
that users can upgrade their existing deployments to.<br>
<br>
Regards,<br>
Daniel<br>
--<br>
|: <a href="http://berrange.com" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" target="_blank">http://libvirt.org</a> -o- <a href="http://virt-manager.org" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" target="_blank">http://autobuild.org</a> -o- <a href="http://search.cpan.org/~danberr/" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" target="_blank">http://entangle-photo.org</a> -o- <a href="http://live.gnome.org/gtk-vnc" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Fri, 22 Nov 2013 14:19:35 +0100<br>
From: Sascha Peilicke <<a href="mailto:speilicke@suse.com">speilicke@suse.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [horizon] Javascript development<br>
improvement<br>
Message-ID: <<a href="mailto:11379465.E1ltjE6RFd@bort.suse.de">11379465.E1ltjE6RFd@bort.suse.de</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
On Friday 22 November 2013 13:13:29 Matthias Runge wrote:<br>
> On 11/21/2013 01:55 PM, Jiri Tomasek wrote:<br>
> > Hi,<br>
> ><br>
> ><br>
> > Regarding less, I don't really care what compiler we use as long as it<br>
> > works. And if we need to provide uncompiled less for production, then<br>
> > let's use Lesscpy.<br>
><br>
> There is at least one bug open against Ubuntu[1], asking to install<br>
> python-lesscpy as well, as customers "often" need to re-create or change<br>
> stylesheets.<br>
<br>
I asked chuck months ago to package it :-)<br>
<br>
> This would imply nodejs in a production environment, when going back to<br>
> less.<br>
><br>
> Just naming the n word here, makes people bite, for whatever reason ;-)<br>
><br>
> Matthias<br>
><br>
> [1]<br>
> <a href="https://bugs.launchpad.net/ubuntu/+source/openstack-dashboard/+bug/1071276" target="_blank">https://bugs.launchpad.net/ubuntu/+source/openstack-dashboard/+bug/1071276</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
--<br>
With kind regards,<br>
Sascha Peilicke<br>
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany<br>
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer HRB 16746 (AG N?rnberg)<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 198 bytes<br>
Desc: This is a digitally signed message part.<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/1012f23e/attachment-0001.pgp" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/1012f23e/attachment-0001.pgp</a>><br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Fri, 22 Nov 2013 14:49:47 +0100 (CET)<br>
From: Maxime Vidori <<a href="mailto:maxime.vidori@enovance.com">maxime.vidori@enovance.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [horizon] Javascript development<br>
improvement<br>
Message-ID:<br>
<<a href="mailto:1003254746.1659898.1385128187231.JavaMail.root@enovance.com">1003254746.1659898.1385128187231.JavaMail.root@enovance.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
>There is at least one bug open against Ubuntu[1], asking to install<br>
>python-lesscpy as well, as customers "often" need to re-create or change<br>
>stylesheets.<br>
><br>
>This would imply nodejs in a production environment, when going back to<br>
>less.<br>
<br>
As long as the css will be the only one included into the package, we cannot run into this issue. If someone wants to modify the less file he could compile it and just copy paste the result into the proper directory.<br>
<br>
>It seems a bit crazy to me to introduce NodeJS as a dependency just for<br>
>the sake of an easy way to run jslint. There are other options<br>
>available that run without NodeJS as a dependency.<br>
<br>
Sadly, the only solutions which try to implement jslint in pure python are in alpha or abandoned. If you have a python library which has the same quality as jslint (which is written by Douglas Crockford himself), I will be glad to take a look at it.<br>
<br>
>There are more implications to running NodeJS even only for<br>
>development. It will likely have an impact on our infrastructure as<br>
>well, since we'll want these checks running on patches up for<br>
>review. Then if it's there for development it increases the risk it<br>
>will creep in as a dependency for our runtime.<br>
<br>
That is a good point, but Selenium also provides external dependencies, like a browser to run into. I do not really know the infrastructure used by jenkins and how we can integrate our solution into, but I do not think it is impossible (I have never got any trouble with the installation of node with the sources in any distro).<br>
<br>
>As for Selenium, are you talking about rewriting our existing Selenium<br>
>tests in Javascript? If so I am opposed to this. The strength of our<br>
>community is in Python, if we want to encourage people to write more<br>
>tests we should make it easy for them to do so.<br>
<br>
Currently we have two Selenium tests in pure python, and all the others are running in a page with qUnit, which is a javascript unit testing framework.<br>
<br>
Lastly, we will start using angularjs as a front-end framework, it provides an advanced testing framework which allows us to get rid of selenium.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Fri, 22 Nov 2013 05:58:11 -0800<br>
From: Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>><br>
To: "Daniel P. Berrange" <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>>, "OpenStack<br>
Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [nova] future fate of nova-network?<br>
Message-ID: <<a href="mailto:528F62F3.2090903@dague.net">528F62F3.2090903@dague.net</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
On 11/22/2013 04:47 AM, Daniel P. Berrange wrote:<br>
> On Fri, Nov 22, 2013 at 11:25:51AM +0000, John Garbutt wrote:<br>
>>>> On Fri, Nov 15, 2013 at 2:21 PM, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>> wrote:<br>
>>>>>> In particular, has there been a decision made about whether it will<br>
>>>>>> definitely be deprecated in some (as yet unspecified) future release, or<br>
>>>>>> whether it will continue to be supported for the foreseeable future?<br>
>>>>><br>
>>>>> We want to deprecate it. There are some things blocking moving forward<br>
>>>>> with this. In short:<br>
>>>>><br>
>>>>> 1) Feature parity (primarily something that satisfies performance and HA<br>
>>>>> requirements addressed by nova-network in multi-host mode)<br>
>>>>><br>
>>>>> 2) Testing and quality parity. The status of Neutron testing in the<br>
>>>>> gate is far inferior to the testing done against nova-network.<br>
>>>>><br>
>>>>> I'm personally more worried about #2 than #1 at this point.<br>
>>>>><br>
>>>>> A major issue is that very few people actually stepped up and agreed to<br>
>>>>> help with #2 at the summit [2]. Only one person signed up to work on<br>
>>>>> tempest issues. Nobody signed up to help with grenade. If this doesn't<br>
>>>>> happen, nova-network can't be deprecated, IMO.<br>
>>>>><br>
>>>>> If significant progress isn't made ASAP this cycle, and ideally by<br>
>>>>> mid-cycle so we can change directions if necessary, then we'll have to<br>
>>>>> discuss what next step to take. That may include un-freezing<br>
>>>>> nova-network so that various people holding on to enhancements to<br>
>>>>> nova-network can start submitting them back. It's a last resort, but I<br>
>>>>> consider it on the table.<br>
>><br>
>> Another approach to help with (1) is in Icehouse we remove the<br>
>> features from nova-network that neutron does not implement. We have<br>
>> warned about deprecation for a good few releases, so its almost OK.<br>
><br>
> We deprecated it on the basis that users would be able to do a upgrade<br>
> to new release providing something that was feature equivalent.<br>
><br>
> We didn't deprecate it on the basis that we were going to remove the<br>
> feature and provide no upgrade path, leaving users screwed.<br>
><br>
> So I don't consider removing features from nova-network to be an<br>
> acceptable approach, until they exist in Neutron or something else<br>
> that users can upgrade their existing deployments to.<br>
<br>
100% agree. -1 on removing nova-network features that people may very<br>
well be using in production, successfully.<br>
<br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 482 bytes<br>
Desc: OpenPGP digital signature<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/6644230e/attachment-0001.pgp" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/6644230e/attachment-0001.pgp</a>><br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Fri, 22 Nov 2013 15:31:03 +0100<br>
From: Matthias Runge <<a href="mailto:mrunge@redhat.com">mrunge@redhat.com</a>><br>
To: Sascha Peilicke <<a href="mailto:speilicke@suse.com">speilicke@suse.com</a>>,<br>
<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [horizon] Javascript development<br>
improvement<br>
Message-ID: <<a href="mailto:528F6AA7.2000704@redhat.com">528F6AA7.2000704@redhat.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
On 11/22/2013 02:19 PM, Sascha Peilicke wrote:<br>
> On Friday 22 November 2013 13:13:29 Matthias Runge wrote:<br>
>> On 11/21/2013 01:55 PM, Jiri Tomasek wrote:<br>
>>> Hi,<br>
>>><br>
>>><br>
>>> Regarding less, I don't really care what compiler we use as<br>
>>> long as it works. And if we need to provide uncompiled less for<br>
>>> production, then let's use Lesscpy.<br>
>><br>
>> There is at least one bug open against Ubuntu[1], asking to<br>
>> install python-lesscpy as well, as customers "often" need to<br>
>> re-create or change stylesheets.<br>
><br>
> I asked chuck months ago to package it :-)<br>
><br>
AFAIK it is packaged already.<br>
<br>
I was not speaking about lesscpy (which might raised your attention<br>
here), but about less compiler in general (or other tools, probably<br>
useful for maintainers/customizers tasks).<br>
<br>
Matthias<br>
<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.15 (GNU/Linux)<br>
Comment: Using GnuPG with Thunderbird - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
<br>
iQEcBAEBAgAGBQJSj2qnAAoJEOnz8qQwcaIWeZcH/jC7RUTUPD+fa9lG92YmYuoU<br>
XiG9xivEVtOrhHlqigb43A6rGVkq7IPEVCnf3nMCwxtVHcoLdy3Pq8QPqFEI9LNv<br>
GrjfoKoFy8R71AuAWVblTWgMxJ/4ffHDny4na4FDiqn02vMCucYvsPAKsNU6m3fU<br>
SaFC1pH0f7/LeVpa13IJuM7XlEKpbPNwKObFfxalIen9ISP+9iQeWlczAr96Z198<br>
tjdPg+2CeXM4Dh+jklYjOQHB5ITxFI3U4ehXCDB+aJS5HnGulL4gF1120zsBScG7<br>
fsTI67n+r0mhMo9rIQdVVJFmK/wpHXzKQi8bsBJctk+hJ1UG9sHNjRJVmmq9SWY=<br>
=7B9B<br>
-----END PGP SIGNATURE-----<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 11<br>
Date: Fri, 22 Nov 2013 18:41:44 +0400<br>
From: Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Neutron][LBaaS] Subteam meeting on<br>
Thursday, 21<br>
Message-ID:<br>
<<a href="mailto:CAJfiwORT9eLVy7c%2B%2BUv5CTWi3vn3ZnVYiu6OxOAWZR-b3W45xg@mail.gmail.com">CAJfiwORT9eLVy7c++Uv5CTWi3vn3ZnVYiu6OxOAWZR-b3W45xg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Meeting logs from the latest meeting:<br>
<br>
<br>
Minutes:<br>
<a href="http://eavesdrop.openstack.org/meetings/neutron_lbaas/2013/neutron_lbaas.2013-11-21-14.00.html" target="_blank">http://eavesdrop.openstack.org/meetings/neutron_lbaas/2013/neutron_lbaas.2013-11-21-14.00.html</a><br>
Minutes (text):<br>
<a href="http://eavesdrop.openstack.org/meetings/neutron_lbaas/2013/neutron_lbaas.2013-11-21-14.00.txt" target="_blank">http://eavesdrop.openstack.org/meetings/neutron_lbaas/2013/neutron_lbaas.2013-11-21-14.00.txt</a><br>
Log:<br>
<a href="http://eavesdrop.openstack.org/meetings/neutron_lbaas/2013/neutron_lbaas.2013-11-21-14.00.log.html" target="_blank">http://eavesdrop.openstack.org/meetings/neutron_lbaas/2013/neutron_lbaas.2013-11-21-14.00.log.html</a><br>
<br>
Thanks,<br>
Eugene.<br>
<br>
<br>
<br>
On Thu, Nov 21, 2013 at 3:04 PM, Eugene Nikanorov<br>
<<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>>wrote:<br>
<br>
> Meeting reminder!<br>
> Today, 14-00 UTC, #openstack-meeting<br>
><br>
> Agenda for the meeting:<br>
> 1) Announcements<br>
> 2) Progress with qa and third-party testing<br>
> 3) Feature design discussions<br>
><br>
> Thanks,<br>
> Eugene.<br>
><br>
><br>
> On Tue, Nov 19, 2013 at 12:30 PM, Eugene Nikanorov <<br>
> <a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>> wrote:<br>
><br>
>> Hi folks,<br>
>><br>
>> Let's meet on #openstack-meeting on Thrsday, 21, at 14-00 UTC<br>
>> We'll discuss current progress and design of some of proposed features.<br>
>><br>
>> Thanks,<br>
>> Eugene.<br>
>><br>
>><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/45ff3779/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/45ff3779/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 12<br>
Date: Fri, 22 Nov 2013 08:57:53 -0600<br>
From: Dolph Mathews <<a href="mailto:dolph.mathews@gmail.com">dolph.mathews@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] How to stage client major releases in<br>
Gerrit?<br>
Message-ID:<br>
<CAC=h7gU-rLwT6iYb=8iUYPJZdDu+uROoqYsQCoRxh0=<a href="mailto:HtUyiyQ@mail.gmail.com">HtUyiyQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On Fri, Nov 22, 2013 at 3:31 AM, Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>>wrote:<br>
<br>
> Robert Collins wrote:<br>
> > I don't understand why branches would be needed here *if* the breaking<br>
> > changes don't impact any supported release of OpenStack.<br>
><br>
> Right -- the trick is what does "supported" mean in that case.<br>
><br>
> When the client libraries were first established as separate<br>
> deliverables, they came up with a blanket statement that the latest<br>
> version could always be used with *any* version of openstack you may<br>
> have. The idea being, if some public cloud was still stuck in pre-diablo<br>
> times, you could still use the same library to address both this public<br>
> cloud and the one which was 2 weeks behind Havana HEAD.<br>
><br>
<br>
I'm curious about the historical circumstance of this requirement -- were<br>
the services supported "master, minus two releases" at the time?<br>
<br>
We're not testing more than two stable releases against the latest clients<br>
in CI today, so I find it odd that we still bother with this claim, without<br>
demonstrating that it's true.<br>
<br>
<br>
><br>
> --<br>
> Thierry Carrez (ttx)<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
--<br>
<br>
-Dolph<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/e497e0d3/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/e497e0d3/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 13<br>
Date: Fri, 22 Nov 2013 08:59:31 -0600<br>
From: Ben Nemec <<a href="mailto:openstack@nemebean.com">openstack@nemebean.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [Oslo] Improving oslo-incubator update.py<br>
Message-ID: <7c5c8991205d2233cdcbe85a7f15b72b@localhost><br>
Content-Type: text/plain; charset=UTF-8; format=flowed<br>
<br>
On 2013-11-22 03:11, Flavio Percoco wrote:<br>
> Greetings,<br>
><br>
> Based on the recent discussion that came out about not having enough<br>
> information in the commit message when syncing oslo-incubator modules,<br>
> I was thinking that besides encouraging people to write better commit<br>
> messages, we could also improve the script we use to sync those<br>
> modules.<br>
><br>
> Some of the changes that I've been thinking of:<br>
><br>
> 1) Store the commit sha from which the module was copied from.<br>
> Every project using oslo, currently keeps the list of modules it<br>
> is using in `openstack-modules.conf` in a `module` parameter. We<br>
> could store, along with the module name, the sha of the commit it<br>
> was last synced from:<br>
><br>
> module=log,commit<br>
><br>
> or<br>
><br>
> module=log<br>
> log=commit<br>
><br>
> 2) Add an 'auto-commit' parameter to the update script that will<br>
> generate a commit message with the short log of the commits where<br>
> the modules being updated were modified. Soemthing like:<br>
><br>
> Syncing oslo-incubator modules<br>
><br>
> log.py:<br>
> commit1: short-message<br>
> commit2: short-message<br>
> commit3: short-message<br>
><br>
> lockutils:<br>
> commit4: short-message<br>
> commit5: short-message<br>
><br>
> #1 will help with figuring out when was the last time a module was<br>
> updated and what changes have been introduced since then.<br>
><br>
> #2 won't be the recommended way for writing commit messages. Oslo<br>
> incubator syncs can have different side-effects in every project.<br>
> However, it could be useful for trivial syncs.<br>
><br>
> Thoughts?<br>
<br>
+1. I've been thinking along the same lines. I always try to include<br>
the git oneline output in my Oslo syncs anyway, but it's not trivial to<br>
figure out the appropriate ones to include so doing it automatically<br>
would be fantastic.<br>
<br>
One other thought I had was to add the ability to split one Oslo sync up<br>
into multiple commits, either one per module, or even one per Oslo<br>
commit for some really large module changes (I'm thinking of the 1000<br>
line db sync someone mentioned recently). It would be more review<br>
churn, but at least it would keep the changes per review down to a more<br>
reasonable level. I'm not positive it would be beneficial, but I<br>
thought I'd mention it.<br>
<br>
-Ben<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 14<br>
Date: Fri, 22 Nov 2013 16:08:53 +0100<br>
From: Imre Farkas <<a href="mailto:ifarkas@redhat.com">ifarkas@redhat.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [horizon] Javascript development<br>
improvement<br>
Message-ID: <<a href="mailto:528F7385.5020208@redhat.com">528F7385.5020208@redhat.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br>
<br>
On 11/22/2013 02:49 PM, Maxime Vidori wrote:<br>
>> It seems a bit crazy to me to introduce NodeJS as a dependency just for<br>
>> the sake of an easy way to run jslint. There are other options<br>
>> available that run without NodeJS as a dependency.<br>
><br>
> Sadly, the only solutions which try to implement jslint in pure python are in alpha or abandoned. If you have a python library which has the same quality as jslint (which is written by Douglas Crockford himself), I will be glad to take a look at it.<br>
<br>
There's a jslint fork called jshint which is able to run in the browser<br>
without any node.js dependency.<br>
<br>
I created a POC patch [1] long time ago to demonstrate its capabilities.<br>
It's integrated with qunit and runs automatically with the horizon test<br>
suite.<br>
<br>
The patch also contains a .jshintrc file for the node.js package but you<br>
can remove it since it's not used by the qunit+jshint test at all.<br>
<br>
Imre<br>
<br>
[1] <a href="https://review.openstack.org/#/c/41087/" target="_blank">https://review.openstack.org/#/c/41087/</a><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 15<br>
Date: Fri, 22 Nov 2013 19:23:43 +0400<br>
From: Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>><br>
To: OpenStack Development Mailing List<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [Neutron][LBaaS] L7 rules design<br>
Message-ID:<br>
<CAJfiwOQ_=<a href="mailto:i6myrDPCAsN-Xha1toUvRZR7YGFby3HYsj75jaKAw@mail.gmail.com">i6myrDPCAsN-Xha1toUvRZR7YGFby3HYsj75jaKAw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi Avishay, lbaas folks,<br>
<br>
I've reviewed the wiki and have some questions/suggestions:<br>
<br>
1) Looks like L7Policy is lacking 'name' attribute in it's description.<br>
However i see little benefit of having a name for this object<br>
2) lbaas-related neutron client commands start with lb-, please fix this.<br>
3) How does L7Policy specifies relation of vip and pool?<br>
4) How default pool will be associated with the vip? Will it be a l7 rule<br>
of special kind?<br>
It is not quite clear what does mean associating vip with pool with policy<br>
if each rule in the policy contains 'SelectedPool' attribute.<br>
5) what is 'action'? What other actions except SELECT_POOL can be?<br>
<br>
In fact my suggestion will be slightly different:<br>
- Instead of having L7Policy which i believe serves only to rules grouping,<br>
we introduce VipPoolAssociation as follows:<br>
<br>
VipPoolAssociation<br>
id,<br>
vip_id,<br>
pool_id,<br>
default - boolean flag for default pool for the vip<br>
<br>
L7Rule then will have vippoolassociation_id (it's better to shorten the<br>
attr name) just like it has policy_id in your proposal. L7Rule doesn't need<br>
SelectedPool attribute since once it attached to VipPoolAssociation, the<br>
rule then points to the pool with pool_id of that association.<br>
In other words, VipPoolAssociation is almost the same as L7Policy but named<br>
closer to it's primary goal of associating vips and pools.<br>
<br>
I would also suggest to add add/delete-rule operation for the association.<br>
<br>
What do you think?<br>
<br>
Thanks,<br>
Eugene.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/4fc1ad2c/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/4fc1ad2c/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 16<br>
Date: Fri, 22 Nov 2013 16:43:40 +0100<br>
From: Rafa? Jaworowski <<a href="mailto:raj@semihalf.com">raj@semihalf.com</a>><br>
To: rbryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>>, <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Cc: Micha? Dubiel <<a href="mailto:md@semihalf.com">md@semihalf.com</a>><br>
Subject: [openstack-dev] FreeBSD hypervisor (bhyve) driver<br>
Message-ID:<br>
<CA+gdeqdNzqsn_8yfRV_=<a href="mailto:iYUXB_TP-HVHuizWFaQkMaUve3PZKA@mail.gmail.com">iYUXB_TP-HVHuizWFaQkMaUve3PZKA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
Russell,<br>
First, thank you for the whiteboard input regarding the blueprint for<br>
FreeBSD hypervisor nova driver:<br>
<a href="https://blueprints.launchpad.net/nova/+spec/freebsd-compute-node" target="_blank">https://blueprints.launchpad.net/nova/+spec/freebsd-compute-node</a><br>
<br>
We were considering libvirt support for bhyve hypervisor as well, only<br>
wouldn't want to do this as the first approach for FreeBSD+OpenStack<br>
integration. We'd rather bring bhyve bindings for libvirt later as<br>
another integration option.<br>
<br>
For FreeBSD host support a native hypervisor driver is important and<br>
desired long-term and we would like to have it anyways. Among things<br>
to consider are the following:<br>
- libvirt package is additional (non-OpenStack), external dependency<br>
(maintained in the 'ports' collection, not included in base system),<br>
while native API (via libvmmapi.so library) is integral part of the<br>
base system.<br>
- libvirt license is LGPL, which might be an important aspect for some users.<br>
<br>
Rafal<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 17<br>
Date: Fri, 22 Nov 2013 10:46:19 -0500<br>
From: Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>><br>
To: Rafa? Jaworowski <<a href="mailto:raj@semihalf.com">raj@semihalf.com</a>>,<br>
<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Cc: Micha? Dubiel <<a href="mailto:md@semihalf.com">md@semihalf.com</a>><br>
Subject: Re: [openstack-dev] FreeBSD hypervisor (bhyve) driver<br>
Message-ID: <<a href="mailto:528F7C4B.7040904@redhat.com">528F7C4B.7040904@redhat.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On 11/22/2013 10:43 AM, Rafa? Jaworowski wrote:<br>
> Russell,<br>
> First, thank you for the whiteboard input regarding the blueprint for<br>
> FreeBSD hypervisor nova driver:<br>
> <a href="https://blueprints.launchpad.net/nova/+spec/freebsd-compute-node" target="_blank">https://blueprints.launchpad.net/nova/+spec/freebsd-compute-node</a><br>
><br>
> We were considering libvirt support for bhyve hypervisor as well, only<br>
> wouldn't want to do this as the first approach for FreeBSD+OpenStack<br>
> integration. We'd rather bring bhyve bindings for libvirt later as<br>
> another integration option.<br>
><br>
> For FreeBSD host support a native hypervisor driver is important and<br>
> desired long-term and we would like to have it anyways. Among things<br>
> to consider are the following:<br>
> - libvirt package is additional (non-OpenStack), external dependency<br>
> (maintained in the 'ports' collection, not included in base system),<br>
> while native API (via libvmmapi.so library) is integral part of the<br>
> base system.<br>
> - libvirt license is LGPL, which might be an important aspect for some users.<br>
<br>
That's perfectly fine if you want to go that route as a first step.<br>
However, that doesn't mean it's appropriate for merging into Nova.<br>
Unless there are strong technical justifications for why this approach<br>
should be taken, I would probably turn down this driver until you were<br>
able to go the libvirt route.<br>
<br>
--<br>
Russell Bryant<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 18<br>
Date: Fri, 22 Nov 2013 07:52:00 -0800<br>
From: Krishna Raman <<a href="mailto:kraman@gmail.com">kraman@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Introducing the new OpenStack service for<br>
Containers<br>
Message-ID:<br>
<<a href="mailto:CAG%2B5PoV4XAMoJY4URQHKCmKQ8fjkbpWehCXUyvarHgj48B1TuQ@mail.gmail.com">CAG+5PoV4XAMoJY4URQHKCmKQ8fjkbpWehCXUyvarHgj48B1TuQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
On Thu, Nov 21, 2013 at 9:58 AM, Sam Alba <<a href="mailto:sam.alba@gmail.com">sam.alba@gmail.com</a>> wrote:<br>
<br>
> On Thu, Nov 21, 2013 at 9:39 AM, Krishna Raman <<a href="mailto:kraman@gmail.com">kraman@gmail.com</a>> wrote:<br>
> ><br>
> > On Thu, Nov 21, 2013 at 8:57 AM, Sam Alba <<a href="mailto:sam.alba@gmail.com">sam.alba@gmail.com</a>> wrote:<br>
> >><br>
> >> I wish we can make a decision during this meeting. Is it confirmed for<br>
> >> Friday 9am pacific?<br>
> ><br>
> ><br>
> > Friday 9am Pacific seems to be the best time for this meeting. Can we use<br>
> > the #openstack-meeting channel for this?<br>
> > If not, then I can find another channel.<br>
> ><br>
> > For the agenda, I propose<br>
> > - going through <a href="https://etherpad.openstack.org/p/containers-service-apiand" target="_blank">https://etherpad.openstack.org/p/containers-service-apiand</a><br>
> > understand capabilities of all container technologies<br>
> > + would like the experts on each of those technologies to fill us in<br>
> > - go over the API proposal and see what we need to change.<br>
><br>
> I think it's too early to go through the API. Let's first go through<br>
> all options discussed before to support containers in openstack<br>
> compute:<br>
> #1 Have this new compute service for containers (other than Nova)<br>
> #2 Extend Nova virt API to support containers<br>
> #3 Support containers API as a third API for Nova<br>
><br>
> Depending how it goes, then it makes sense to do an overview of the API I<br>
> think.<br>
><br>
> What do you guys think?<br>
><br>
><br>
Will go over the options on the table briefly today. As we discussed during<br>
the design session, it will be important to figure out the delta between<br>
Nova VM API and what is required for containers. After we have the delta,<br>
we can decide on which of those 3 options makes sense.<br>
<br>
--kr<br>
<br>
<br>
><br>
> >> On Thu, Nov 21, 2013 at 8:24 AM, Chuck Short <<a href="mailto:chuck.short@canonical.com">chuck.short@canonical.com</a><br>
> ><br>
> >> wrote:<br>
> >> > Hi<br>
> >> ><br>
> >> > Has a decision happened when this meeting is going to take place,<br>
> >> > assuming<br>
> >> > it is still taking place tomorrow.<br>
> >> ><br>
> >> > Regards<br>
> >> > chuck<br>
> >> ><br>
> >> ><br>
> >> > On Mon, Nov 18, 2013 at 7:58 PM, Krishna Raman <<a href="mailto:kraman@gmail.com">kraman@gmail.com</a>><br>
> wrote:<br>
> >> >><br>
> >> >><br>
> >> >> On Nov 18, 2013, at 4:30 PM, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>><br>
> wrote:<br>
> >> >><br>
> >> >> On 11/18/2013 06:30 PM, Dan Smith wrote:<br>
> >> >><br>
> >> >> Not having been at the summit (maybe the next one), could somebody<br>
> >> >> give a really short explanation as to why it needs to be a separate<br>
> >> >> service? It sounds like it should fit within the Nova area. It is,<br>
> >> >> after all, just another hypervisor type, or so it seems.<br>
> >> >><br>
> >> >><br>
> >> >> But it's not just another hypervisor. If all you want from your<br>
> >> >> containers is lightweight VMs, then nova is a reasonable place to put<br>
> >> >> that (and it's there right now). If, however, you want to expose the<br>
> >> >> complex and flexible attributes of a container, such as being able to<br>
> >> >> overlap filesystems, have fine-grained control over what is shared<br>
> with<br>
> >> >> the host OS, look at the processes within a container, etc, then nova<br>
> >> >> ends up needing quite a bit of change to support that.<br>
> >> >><br>
> >> >> I think the overwhelming majority of folks in the room, after<br>
> >> >> discussing<br>
> >> >> it, agreed that Nova is infrastructure and containers is more of a<br>
> >> >> platform thing. Making it a separate service lets us define a<br>
> mechanism<br>
> >> >> to manage these that makes much more sense than treating them like<br>
> VMs.<br>
> >> >> Using Nova to deploy VMs that run this service is the right approach,<br>
> >> >> IMHO. Clayton put it very well, I think:<br>
> >> >><br>
> >> >> If the thing you want to deploy has a kernel, then you need Nova. If<br>
> >> >> your thing runs on a kernel, you want $new_service_name.<br>
> >> >><br>
> >> >> I agree.<br>
> >> >><br>
> >> >> Note that this is just another service under the compute project (or<br>
> >> >> program, or whatever the correct terminology is this week).<br>
> >> >><br>
> >> >><br>
> >> >> The Compute program is correct. That is established terminology as<br>
> >> >> defined by the TC in the last cycle.<br>
> >> >><br>
> >> >> So while<br>
> >> >> distinct from Nova in terms of code, development should be tightly<br>
> >> >> integrated until (and if at some point) it doesn't make sense.<br>
> >> >><br>
> >> >><br>
> >> >> And it may share a whole bunch of the code.<br>
> >> >><br>
> >> >> Another way to put this: The API requirements people have for<br>
> >> >> containers include a number of features considered outside of the<br>
> >> >> current scope of Nova (short version: Nova's scope stops before going<br>
> >> >> *inside* the servers it creates, except file injection, which we plan<br>
> >> >> to<br>
> >> >> remove anyway). That presents a problem. A new service is one<br>
> >> >> possible<br>
> >> >> solution.<br>
> >> >><br>
> >> >> My view of the outcome of the session was not "it *will* be a new<br>
> >> >> service". Instead, it was, "we *think* it should be a new service,<br>
> but<br>
> >> >> let's do some more investigation to decide for sure".<br>
> >> >><br>
> >> >> The action item from the session was to go off and come up with a<br>
> >> >> proposal for what a new service would look like. In particular, we<br>
> >> >> needed a proposal for what the API would look like. With that in<br>
> hand,<br>
> >> >> we need to come back and ask the question again of whether a new<br>
> >> >> service<br>
> >> >> is the right answer.<br>
> >> >><br>
> >> >> I see 3 possible solutions here:<br>
> >> >><br>
> >> >> 1) Expand the scope of Nova to include all of the things people want<br>
> to<br>
> >> >> be able to do with containers.<br>
> >> >><br>
> >> >> This is my least favorite option. Nova is already really big. We've<br>
> >> >> worked to split things out (Networking, Block Storage, Images) to<br>
> keep<br>
> >> >> it under control. I don't think a significant increase in scope is a<br>
> >> >> smart move for Nova's future.<br>
> >> >><br>
> >> >> 2) Declare containers as explicitly out of scope and start a new<br>
> >> >> project<br>
> >> >> with its own API.<br>
> >> >><br>
> >> >> That is what is being proposed here.<br>
> >> >><br>
> >> >> 3) Some middle ground that is a variation of #2. Consider Ironic.<br>
> The<br>
> >> >> idea is that Nova's API will still be used for basic provisioning,<br>
> >> >> which<br>
> >> >> Nova will implement by talking to Ironic. However, there are a lot<br>
> of<br>
> >> >> baremetal management things that don't fit in Nova at all, and those<br>
> >> >> only exist in Ironic's API.<br>
> >> >><br>
> >> >> I wanted to mention this option for completeness, but I don't<br>
> actually<br>
> >> >> think it's the right choice here. With Ironic you have a physical<br>
> >> >> resource (managed by Ironic), and then instances of an image running<br>
> on<br>
> >> >> these physical resources (managed by Nova).<br>
> >> >><br>
> >> >> With containers, there's a similar line. You have instances of<br>
> >> >> containers (managed either by Nova or the new service) running on<br>
> >> >> servers (managed by Nova). I think there is a good line for<br>
> separating<br>
> >> >> concerns, with a container service on top of Nova.<br>
> >> >><br>
> >> >><br>
> >> >> Let's ask ourselves: How much overlap is there between the current<br>
> >> >> compute API and a proposed containers API? Effectively, what's the<br>
> >> >> diff? How much do we expect this diff to change in the coming years?<br>
> >> >><br>
> >> >> The current diff demonstrates a significant clash with the current<br>
> >> >> scope<br>
> >> >> of Nova. I also expect a lot of innovation around containers in the<br>
> >> >> next few years, which will result in wanting to do new cool things in<br>
> >> >> the API. I feel that all of this justifies a new API service to best<br>
> >> >> position ourselves for the long term.<br>
> >> >><br>
> >> >><br>
> >> >> +1<br>
> >> >><br>
> >> >> We need to come up with the API first before we decide if this is a<br>
> new<br>
> >> >> service or just something that<br>
> >> >> needs to be added to Nova,<br>
> >> >><br>
> >> >> How about we have all interested parties meet on IRC or conf. call<br>
> and<br>
> >> >> discuss the suggested REST API,<br>
> >> >> open questions and architecture.<br>
> >> >><br>
> >> >> If you are interested please add your name to the participant list on<br>
> >> >> <a href="https://etherpad.openstack.org/p/containers-service" target="_blank">https://etherpad.openstack.org/p/containers-service</a>.<br>
> >> >><br>
> >> >> I have also set up a doodle poll at<br>
> <a href="http://doodle.com/w7y5qcdvq9i36757" target="_blank">http://doodle.com/w7y5qcdvq9i36757</a><br>
> >> >> to<br>
> >> >> gather a times when a majority<br>
> >> >> of us are available to discuss on IRC.<br>
> >> >><br>
> >> >> --<br>
> >> >> Krishna Raman<br>
> >> >><br>
> >> >> PS: Sorry if you see this email twice. I am having some issues with<br>
> >> >> list<br>
> >> >> subscription.<br>
> >> >><br>
> >> >><br>
> >> >> --<br>
> >> >> Russell Bryant<br>
> >> >><br>
> >> >> _______________________________________________<br>
> >> >> OpenStack-dev mailing list<br>
> >> >> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> >> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >> >><br>
> >> >><br>
> >> >><br>
> >> >> _______________________________________________<br>
> >> >> OpenStack-dev mailing list<br>
> >> >> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> >> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >> >><br>
> >> ><br>
> >> ><br>
> >> > _______________________________________________<br>
> >> > OpenStack-dev mailing list<br>
> >> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> >> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >> ><br>
> >><br>
> >><br>
> >><br>
> >> --<br>
> >> @sam_alba<br>
> >><br>
> >> _______________________________________________<br>
> >> OpenStack-dev mailing list<br>
> >> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> >> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
><br>
><br>
><br>
> --<br>
> @sam_alba<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/cf266bfb/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/cf266bfb/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 19<br>
Date: Fri, 22 Nov 2013 07:53:31 -0800<br>
From: Krishna Raman <<a href="mailto:kraman@gmail.com">kraman@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Introducing the new OpenStack service for<br>
Containers<br>
Message-ID:<br>
<<a href="mailto:CAG%2B5PoV28ZM_t790mK8yja3VqK8%2BqmyLNqnYkY02NNiMOq2y7w@mail.gmail.com">CAG+5PoV28ZM_t790mK8yja3VqK8+qmyLNqnYkY02NNiMOq2y7w@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
On Thu, Nov 21, 2013 at 11:07 AM, Tim Bell <<a href="mailto:Tim.Bell@cern.ch">Tim.Bell@cern.ch</a>> wrote:<br>
<br>
><br>
><br>
> Can we make sure that the costs for the end users are also considered as<br>
> part of this ?<br>
><br>
><br>
><br>
> - Configuration management will need further modules<br>
><br>
> - Dashboard confusion as we get multiple tabs<br>
><br>
> - Accounting, Block Storage, Networking, Orchestration confusion<br>
> as the concepts diverge<br>
><br>
><br>
><br>
> Is this really a good idea to create another project considering the needs<br>
> of the whole openstack community ?<br>
><br>
<br>
Hi Tim,<br>
<br>
We have not made the determination that a new service is necessary yet. All<br>
the discussion today will be about is to see what the differences are.<br>
After we have that, we will go back to discuss with Nova team and see if<br>
the split is even necessary.<br>
<br>
--kr<br>
<br>
<br>
><br>
><br>
> Tim<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/4bc1b438/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/4bc1b438/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 20<br>
Date: Fri, 22 Nov 2013 10:58:46 -0500<br>
From: Mike Spreitzer <<a href="mailto:mspreitz@us.ibm.com">mspreitz@us.ibm.com</a>><br>
To: "OpenStack Development Mailing List \(not for usage questions\)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a<br>
modest proposal for an external scheduler in our lifetime<br>
Message-ID:<br>
<<a href="mailto:OF2D54E8FB.F2526DFE-ON85257C2B.00578C0A-85257C2B.0057C750@us.ibm.com">OF2D54E8FB.F2526DFE-ON85257C2B.00578C0A-85257C2B.0057C750@us.ibm.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
I'm still a newbie here, so can not claim my Nova skills are even<br>
"modest". But I'd like to track this, if nothing more.<br>
<br>
Thanks,<br>
Mike<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/188326aa/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/188326aa/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 21<br>
Date: Fri, 22 Nov 2013 11:17:13 -0500<br>
From: Jonathan Proulx <<a href="mailto:jon@jonproulx.com">jon@jonproulx.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [nova] future fate of nova-network?<br>
Message-ID:<br>
<CABZB-sj6K15Ei0xBZnHxim=<a href="mailto:AeG_Cx0kaTsuADaBxCykH3Nyz0Q@mail.gmail.com">AeG_Cx0kaTsuADaBxCykH3Nyz0Q@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
To add to the screams of others removing features from nova-network to<br>
achieve parity with neutron is a non starter, and it rather scares me<br>
to hear it suggested.<br>
<br>
I do try not to rant in public, especially about things I'm not<br>
competent to really help fix, but I can't really contain this one any<br>
longer:<br>
<br>
<rant><br>
As an operator I've moved my cloud neutron already, but while it<br>
provides many advanced features it still really falls down on<br>
providing simple solutions for simple use cases. Most operators I've<br>
talked to informally hate it for that and don't want to go near it and<br>
for new users, even those with advanced skill sets, neutron causes by<br>
far the most cursing and rage quits I've seen (again just my<br>
subjective observation) on IRC, Twitter, and the mailing lists.<br>
<br>
Providing feature parity and easy cut over *should have been* priority<br>
1 when quantum split out of nova as it was for cinder (which was a<br>
delightful and completely unnoticable transition)<br>
<br>
We need feature parity and complexity parity with nova-network for the<br>
use cases it covers. The failure to do so or even have a reasonable<br>
plan to do so is currently the worst thing about openstack.<br>
</rant><br>
<br>
I do appreciate the work being done on advanced networking features in<br>
neutron, I'm even using some of them, just someone please bring focus<br>
back on the basics.<br>
<br>
-Jon<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 22<br>
Date: Fri, 22 Nov 2013 16:21:50 +0000<br>
From: Duncan Thomas <<a href="mailto:duncan.thomas@gmail.com">duncan.thomas@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Cinder][Glance] OSLO update<br>
Message-ID:<br>
<CAOyZ2aHXe2S6F1s5HApWJA40jeV+cnUvphEA1KA2FEBfAy=_<a href="mailto:ZQ@mail.gmail.com">ZQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
On 22 November 2013 12:27, Elena Ezhova <<a href="mailto:eezhova@mirantis.com">eezhova@mirantis.com</a>> wrote:<br>
> But what if I want to update some module that consists of ten or even more<br>
> files (like rpc or db) and each of these files has quite a long change log?<br>
> In that case the commit message may turn out to be really long even if only<br>
> commit ids and names are included.<br>
<br>
<br>
A message that is too long is definitely a better problem to have than<br>
a message that is missing important details.<br>
<br>
To turn the question round, how can a reviewer review a change that<br>
includes ten or even more files without any information on what<br>
changed and why? rpc and db are extremely difficult imports to review,<br>
and I've found problems in the last two I looked at.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 23<br>
Date: Fri, 22 Nov 2013 11:24:18 -0500<br>
From: Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [nova] future fate of nova-network?<br>
Message-ID: <<a href="mailto:528F8532.3000400@redhat.com">528F8532.3000400@redhat.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
On 11/22/2013 11:17 AM, Jonathan Proulx wrote:<br>
> To add to the screams of others removing features from nova-network to<br>
> achieve parity with neutron is a non starter, and it rather scares me<br>
> to hear it suggested.<br>
<br>
-1 from me too, so everyone can take a deep breath on this. :-)<br>
<br>
> Providing feature parity and easy cut over *should have been* priority<br>
> 1 when quantum split out of nova as it was for cinder (which was a<br>
> delightful and completely unnoticable transition)<br>
<br>
+1<br>
<br>
I think the experience with Neutron provides us some very good insight<br>
for future project splits/replacements. We're working on establishing<br>
more clear requirements for project incubation and graduation in the TC.<br>
One note I put down was that we should require that projects stay<br>
completely focused on being able to deprecate their replacement before<br>
adding *anything* else whenever possible.<br>
<br>
A good example is the current discussion around a new scheduling<br>
service. There have been lots of big ideas around this. Robert Collins<br>
just started a thread about a proposal to start this project but with a<br>
very strict scope of being able to replace nova-scheduler, and *nothing*<br>
more until that's completely done. I like that approach quite a bit.<br>
<br>
--<br>
Russell Bryant<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 24<br>
Date: Fri, 22 Nov 2013 16:24:23 +0000<br>
From: Duncan Thomas <<a href="mailto:duncan.thomas@gmail.com">duncan.thomas@gmail.com</a>><br>
To: <a href="mailto:openstack@nemebean.com">openstack@nemebean.com</a>, "OpenStack Development Mailing List (not<br>
for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Oslo] Improving oslo-incubator update.py<br>
Message-ID:<br>
<<a href="mailto:CAOyZ2aEaUrzTNGeoxT9yejbxqKfvxaDmsfRuf%2B1HBSKN7fcNGQ@mail.gmail.com">CAOyZ2aEaUrzTNGeoxT9yejbxqKfvxaDmsfRuf+1HBSKN7fcNGQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
On 22 November 2013 14:59, Ben Nemec <<a href="mailto:openstack@nemebean.com">openstack@nemebean.com</a>> wrote:<br>
<br>
> One other thought I had was to add the ability to split one Oslo sync up<br>
> into multiple commits, either one per module, or even one per Oslo commit<br>
> for some really large module changes (I'm thinking of the 1000 line db sync<br>
> someone mentioned recently). It would be more review churn, but at least it<br>
> would keep the changes per review down to a more reasonable level. I'm not<br>
> positive it would be beneficial, but I thought I'd mention it.<br>
<br>
Cinder (often but not always me) tends to reject merges that do more<br>
that one module at a time, because it makes it far harder to review<br>
and spot problems, so some from of automation of this would be great.<br>
<br>
--<br>
Duncan Thomas<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 25<br>
Date: Fri, 22 Nov 2013 16:32:59 +0000<br>
From: "Daniel P. Berrange" <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [nova] future fate of nova-network?<br>
Message-ID: <<a href="mailto:20131122163259.GH16339@redhat.com">20131122163259.GH16339@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
On Fri, Nov 22, 2013 at 11:24:18AM -0500, Russell Bryant wrote:<br>
> On 11/22/2013 11:17 AM, Jonathan Proulx wrote:<br>
> > To add to the screams of others removing features from nova-network to<br>
> > achieve parity with neutron is a non starter, and it rather scares me<br>
> > to hear it suggested.<br>
><br>
> -1 from me too, so everyone can take a deep breath on this. :-)<br>
><br>
> > Providing feature parity and easy cut over *should have been* priority<br>
> > 1 when quantum split out of nova as it was for cinder (which was a<br>
> > delightful and completely unnoticable transition)<br>
><br>
> +1<br>
><br>
> I think the experience with Neutron provides us some very good insight<br>
> for future project splits/replacements. We're working on establishing<br>
> more clear requirements for project incubation and graduation in the TC.<br>
> One note I put down was that we should require that projects stay<br>
> completely focused on being able to deprecate their replacement before<br>
> adding *anything* else whenever possible.<br>
><br>
> A good example is the current discussion around a new scheduling<br>
> service. There have been lots of big ideas around this. Robert Collins<br>
> just started a thread about a proposal to start this project but with a<br>
> very strict scope of being able to replace nova-scheduler, and *nothing*<br>
> more until that's completely done. I like that approach quite a bit.<br>
<br>
I'd suggest something even stronger. If we want to split out code into<br>
a new project, we should always follow the approach used for cinder.<br>
ie the existing fully functional code should be pulled out as is, and<br>
work then progress from there. That ensures we'd always have feature<br>
parity from the very start. Yes, you might have to then do a large<br>
amount of refactoring to get to where you want to be, but IMHO that's<br>
preferrable to starting something from scratch and forgetting to cover<br>
existing use cases.<br>
<br>
Daniel<br>
--<br>
|: <a href="http://berrange.com" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" target="_blank">http://libvirt.org</a> -o- <a href="http://virt-manager.org" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" target="_blank">http://autobuild.org</a> -o- <a href="http://search.cpan.org/~danberr/" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" target="_blank">http://entangle-photo.org</a> -o- <a href="http://live.gnome.org/gtk-vnc" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 26<br>
Date: Fri, 22 Nov 2013 11:34:37 -0500 (EST)<br>
From: Clayton Coleman <<a href="mailto:ccoleman@redhat.com">ccoleman@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [Solum] Working group on language packs<br>
Message-ID:<br>
<<a href="mailto:1788852399.27667197.1385138077079.JavaMail.root@redhat.com">1788852399.27667197.1385138077079.JavaMail.root@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
I have updated the language pack (name subject to change) blueprint with the outcomes from the face2face meetings, and drafted a specification that captures the discussion so far. The spec is centered around the core idea of transitioning base images into deployable images (that can be stored in Nova and sent to Glance). These are *DRAFT* and are intended for public debate.<br>
<br>
<a href="https://blueprints.launchpad.net/solum/+spec/lang-pack" target="_blank">https://blueprints.launchpad.net/solum/+spec/lang-pack</a><br>
<a href="https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/BuildingSourceIntoDeploymentArtifacts" target="_blank">https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/BuildingSourceIntoDeploymentArtifacts</a><br>
<br>
Please take this opportunity to review these documents and offer criticism and critique via the ML - I will schedule a follow up deep dive for those who expressed interest in participation [1] after US Thanksgiving.<br>
<br>
[1] <a href="https://etherpad.openstack.org/p/SolumWorkshopTrack1Notes" target="_blank">https://etherpad.openstack.org/p/SolumWorkshopTrack1Notes</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 27<br>
Date: Fri, 22 Nov 2013 08:47:13 -0800<br>
From: Clint Byrum <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>><br>
To: openstack-dev <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Introducing the new OpenStack service for<br>
Containers<br>
Message-ID: <1385137957-sup-2694@clint-HP><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Excerpts from Thierry Carrez's message of 2013-11-22 01:50:39 -0800:<br>
> Tim Bell wrote:<br>
> > Can we make sure that the costs for the end users are also considered as<br>
> > part of this ?<br>
> ><br>
> > - Configuration management will need further modules<br>
> > - Dashboard confusion as we get multiple tabs<br>
> > - Accounting, Block Storage, Networking, Orchestration<br>
> > confusion as the concepts diverge<br>
> ><br>
> > Is this really a good idea to create another project considering the<br>
> > needs of the whole openstack community ?<br>
><br>
> Personally, it will have to prove a really different API and set of use<br>
> cases to justify the cost of a separate project. I'm waiting to see what<br>
> they come up with, but IMHO it's "compute" in both cases. We've seen<br>
> with the libvirt-sandbox discussion that using technology (hypervisor<br>
> vs. container) to draw the line between the use cases is a bit<br>
> over-simplifying the problem.<br>
><br>
<br>
Agreed, I think it has been over simplified, but that is what you do<br>
when you're not driven by a well understood real use-case, something I<br>
have yet to see from this discussion.<br>
<br>
> I don't really want us to create a container service and end up<br>
> implementing the same hypervisor backends than in Nova, just because<br>
> hypervisors can perfectly also be used to serve lightweight<br>
> application-centric workloads. Or the other way around (keep Docker<br>
> support in Nova since you can perfectly run an OS in a container). At<br>
> first glance, extending the Nova API to also cover lightweight<br>
> app-centric use cases would avoid a ton of duplication...<br>
><br>
<br>
Agreed. There are a few weird things that come to mind though. One of<br>
those is that I imagine users would like to do something like this:<br>
<br>
host_id=$(container-thing allocate-host --flavor small appserver)<br>
db_id=$(container-thing allocate-host --flavor huge dbserver)<br>
app_id=$(container-thing run --host $host_id --image app-image)<br>
proxy_id=$(container-thing run --host $host_id --image proxy-image)<br>
cache_id=$(container-thing run --host $host_id --image cache-image)<br>
db_id=$(container-thing run --host $db_id)<br>
<br>
As in, they'd probably like to have VMs spun up and then chopped up<br>
into containers. If this is implemented first inside nova, that may end<br>
up being a rats nest and hard to separate later. The temptation to use<br>
private API's is really strong. But if it is outside nova, the separation<br>
stays clear and the two can be used without one-another very easily.<br>
<br>
> If the main concern is to keep Nova small and manageable, I'd rather rip<br>
> out pieces like nova-network or the scheduler, which are clearly not<br>
> "compute".<br>
><br>
<br>
Indeed, and those things are under way. :)<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 28<br>
Date: Fri, 22 Nov 2013 08:49:09 -0800<br>
From: Krishna Raman <<a href="mailto:kraman@gmail.com">kraman@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Introducing the new OpenStack service for<br>
Containers<br>
Message-ID:<br>
<<a href="mailto:CAG%2B5PoXFzadya2xk8_1PX8sXOWuSQzfGWCLyp8JP0BWJ-_%2B7xw@mail.gmail.com">CAG+5PoXFzadya2xk8_1PX8sXOWuSQzfGWCLyp8JP0BWJ-_+7xw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Reminder: We are meting in about 15 minutes on #openstack-meeting channel.<br>
<br>
--Krishna<br>
<br>
<br>
On Fri, Nov 22, 2013 at 7:53 AM, Krishna Raman <<a href="mailto:kraman@gmail.com">kraman@gmail.com</a>> wrote:<br>
<br>
><br>
><br>
><br>
> On Thu, Nov 21, 2013 at 11:07 AM, Tim Bell <<a href="mailto:Tim.Bell@cern.ch">Tim.Bell@cern.ch</a>> wrote:<br>
><br>
>><br>
>><br>
>> Can we make sure that the costs for the end users are also considered as<br>
>> part of this ?<br>
>><br>
>><br>
>><br>
>> - Configuration management will need further modules<br>
>><br>
>> - Dashboard confusion as we get multiple tabs<br>
>><br>
>> - Accounting, Block Storage, Networking, Orchestration<br>
>> confusion as the concepts diverge<br>
>><br>
>><br>
>><br>
>> Is this really a good idea to create another project considering the<br>
>> needs of the whole openstack community ?<br>
>><br>
><br>
> Hi Tim,<br>
><br>
> We have not made the determination that a new service is necessary yet.<br>
> All the discussion today will be about is to see what the differences are.<br>
> After we have that, we will go back to discuss with Nova team and see if<br>
> the split is even necessary.<br>
><br>
> --kr<br>
><br>
><br>
>><br>
>><br>
>> Tim<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/3ad1b0ee/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/3ad1b0ee/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 29<br>
Date: Fri, 22 Nov 2013 11:53:39 -0500<br>
From: Mike Spreitzer <<a href="mailto:mspreitz@us.ibm.com">mspreitz@us.ibm.com</a>><br>
To: "Daniel P. Berrange" <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>>, "OpenStack Development<br>
Mailing List \(not for usage questions\)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [nova] future fate of nova-network?<br>
Message-ID:<br>
<<a href="mailto:OF2A8C740E.C19403E9-ON85257C2B.005CBA5D-85257C2B.005CCD94@us.ibm.com">OF2A8C740E.C19403E9-ON85257C2B.005CBA5D-85257C2B.005CCD94@us.ibm.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
"Daniel P. Berrange" <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>> wrote on 11/22/2013 11:32:59<br>
AM:<br>
<br>
> > A good example is the current discussion around a new scheduling<br>
> > service. There have been lots of big ideas around this. Robert<br>
Collins<br>
> > just started a thread about a proposal to start this project but with<br>
a<br>
> > very strict scope of being able to replace nova-scheduler, and<br>
*nothing*<br>
> > more until that's completely done. I like that approach quite a bit.<br>
><br>
> I'd suggest something even stronger. If we want to split out code into<br>
> a new project, we should always follow the approach used for cinder.<br>
> ie the existing fully functional code should be pulled out as is, and<br>
> work then progress from there. That ensures we'd always have feature<br>
> parity from the very start. Yes, you might have to then do a large<br>
> amount of refactoring to get to where you want to be, but IMHO that's<br>
> preferrable to starting something from scratch and forgetting to cover<br>
> existing use cases.<br>
<br>
I think that is what Robert is saying.<br>
<br>
Regards,<br>
Mike<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/01659b6a/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/01659b6a/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 30<br>
Date: Fri, 22 Nov 2013 17:01:40 +0000 (UTC)<br>
From: Khanh-Toan Tran <<a href="mailto:khanh-toan.tran@cloudwatt.com">khanh-toan.tran@cloudwatt.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a<br>
modest proposal for an external scheduler in our lifetime<br>
Message-ID:<br>
<<a href="mailto:969288672.14943277.1385139700462.JavaMail.root@cloudwatt.com">969288672.14943277.1385139700462.JavaMail.root@cloudwatt.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Dear all,<br>
<br>
I'm very interested in this subject as well. Actually there is also a discussion of the possibility of an independent scheduler in the mailisg list:<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2013-November/019518.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-November/019518.html</a><br>
<br>
Would it be possible to discuss about this subject in the next Scheduler meeting Nov 26th?<br>
<br>
Best regards,<br>
<br>
Toan<br>
<br>
----- Original Message -----<br>
From: "Mike Spreitzer" <<a href="mailto:mspreitz@us.ibm.com">mspreitz@us.ibm.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Sent: Friday, November 22, 2013 4:58:46 PM<br>
Subject: Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime<br>
<br>
I'm still a newbie here, so can not claim my Nova skills are even "modest". But I'd like to track this, if nothing more.<br>
<br>
Thanks,<br>
Mike<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 31<br>
Date: Fri, 22 Nov 2013 12:06:30 -0500 (EST)<br>
From: Julie Pichon <<a href="mailto:jpichon@redhat.com">jpichon@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [horizon] Javascript development<br>
improvement<br>
Message-ID:<br>
<<a href="mailto:532370933.39209272.1385139990948.JavaMail.root@redhat.com">532370933.39209272.1385139990948.JavaMail.root@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
"Maxime Vidori" <<a href="mailto:maxime.vidori@enovance.com">maxime.vidori@enovance.com</a>> wrote:<br>
> >There is at least one bug open against Ubuntu[1], asking to install<br>
> >python-lesscpy as well, as customers "often" need to re-create or change<br>
> >stylesheets.<br>
> ><br>
> >This would imply nodejs in a production environment, when going back to<br>
> >less.<br>
><br>
> As long as the css will be the only one included into the package, we cannot<br>
> run into this issue. If someone wants to modify the less file he could<br>
> compile it and just copy paste the result into the proper directory.<br>
<br>
This doesn't sound particularly friendly, I think what Matthias was<br>
getting at is that there are requests from users who want to be able to<br>
modify the CSS directly.<br>
<br>
> >It seems a bit crazy to me to introduce NodeJS as a dependency just for<br>
> >the sake of an easy way to run jslint. There are other options<br>
> >available that run without NodeJS as a dependency.<br>
><br>
> Sadly, the only solutions which try to implement jslint in pure python are in<br>
> alpha or abandoned. If you have a python library which has the same quality<br>
> as jslint (which is written by Douglas Crockford himself), I will be glad to<br>
> take a look at it.<br>
<br>
Sure, I'll look into it. There seems to be also Javascript-based<br>
solutions that could be viable. If anyone has recommendations based on<br>
past experience, please let me know. The patch Imre linked to looks<br>
like a good start!<br>
<br>
> >There are more implications to running NodeJS even only for<br>
> >development. It will likely have an impact on our infrastructure as<br>
> >well, since we'll want these checks running on patches up for<br>
> >review. Then if it's there for development it increases the risk it<br>
> >will creep in as a dependency for our runtime.<br>
><br>
> That is a good point, but Selenium also provides external dependencies, like<br>
> a browser to run into. I do not really know the infrastructure used by<br>
> jenkins and how we can integrate our solution into, but I do not think it is<br>
> impossible (I have never got any trouble with the installation of node with<br>
> the sources in any distro).<br>
<br>
Selenium is already integrated with our Jenkins gate. I don't think it<br>
hurts either to run the tests in an environment similar to what they<br>
need to work in in the end.<br>
<br>
> >As for Selenium, are you talking about rewriting our existing Selenium<br>
> >tests in Javascript? If so I am opposed to this. The strength of our<br>
> >community is in Python, if we want to encourage people to write more<br>
> >tests we should make it easy for them to do so.<br>
><br>
> Currently we have two Selenium tests in pure python, and all the others are<br>
> running in a page with qUnit, which is a javascript unit testing framework.<br>
><br>
> Lastly, we will start using angularjs as a front-end framework, it provides<br>
> an advanced testing framework which allows us to get rid of selenium.<br>
<br>
I don't think Selenium is going away, and efforts have started around<br>
using it as well for our integration tests [0]. Looking at the current<br>
AngularJS patch up for review, it is testable without requiring<br>
NodeJS. From the initial mailing list discussion [1], my understanding<br>
is that we're planning on using a specific AngularJS feature, not<br>
rewriting everything with it. Changing our build system to accommodate<br>
this seems like getting a bit ahead of ourselves.<br>
<br>
Julie<br>
<br>
[0] <a href="https://blueprints.launchpad.net/horizon/+spec/selenium-integration-testing" target="_blank">https://blueprints.launchpad.net/horizon/+spec/selenium-integration-testing</a><br>
[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-November/018850.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-November/018850.html</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 32<br>
Date: Fri, 22 Nov 2013 17:12:41 +0000<br>
From: Jarret Raim <<a href="mailto:jarret.raim@RACKSPACE.COM">jarret.raim@RACKSPACE.COM</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Keystone][Oslo] Future of Key<br>
Distribution Server, Trusted Messaging<br>
Message-ID: <<a href="mailto:CEB4EB99.82E5D%25jarret.raim@rackspace.com">CEB4EB99.82E5D%jarret.raim@rackspace.com</a>><br>
Content-Type: text/plain; charset="euc-kr"<br>
<br>
On 11/21/13, 7:51 PM, "Jamie Lennox" <<a href="mailto:jamielennox@redhat.com">jamielennox@redhat.com</a>> wrote:<br>
<br>
<br>
>So i've a feeling that this was proposed and dismissed once before. I<br>
>don't remember why.<br>
><br>
>So my concern with barbican is that i'm under the impression that<br>
>barbican was going to be an 'overcloud' service. That's a really bad way<br>
>of putting it, but it is service and user facing and discovered via the<br>
>service catalog.<br>
><br>
>This feature will need to be configured at a lower level (runs in<br>
>situations without a token) and so we will need to configure the<br>
>services to point to an IP for the KDS service.<br>
<br>
Why would there be a need for token less authentication? My understanding<br>
of the feature is that each service account would have a KDS key<br>
associated with it. This means that each account would need to<br>
authenticate to Keystone before talking to Barbican. Are there service<br>
accounts that don?t have a keystone account?<br>
<br>
><br>
>Is this an expected deployment of barbican (i can't see why not)?<br>
<br>
We certainly could enable this if needed. We already create separate uwsgi<br>
processes for the main and admin apis. We could create another one for the<br>
KDS. I?d rather not do that unless we have to though.<br>
<br>
<br>
Jarret<br>
<br>
<br>
<br>
><br>
>Jamie<br>
><br>
>On Thu, 2013-11-21 at 20:08 +0000, Jarret Raim wrote:<br>
>> The Barbican team has been taking a look at the KDS feature and the<br>
>> proposed patch and I think this may be better placed in Barbican rather<br>
>> than Keystone. The patch, from what I can tell, seems to require that a<br>
>> service account create & use a key under its own tenant. In this use<br>
>>case,<br>
>> Barbican can handle the entire exchange and Keystone can just provide<br>
>> auth/auth for the process. This would allow for some great additional<br>
>> features including guaranteed entropy and additional security through<br>
>>the<br>
>> use of HSMs, auditing / logging, etc.<br>
>><br>
>> Barbican is pretty far along at this point and it doesn?t appear to be a<br>
>> huge amount of work to move the patch over as it doesn?t seem to use any<br>
>> Keystone internals.<br>
>><br>
>> What would people think about this approach? We?re happy to help move<br>
>>the<br>
>> patch over and I?m certainly happy to merge it as it feels like a good<br>
>> feature for barbican.<br>
>><br>
>><br>
>><br>
>><br>
>> Jarret<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On 11/21/13, 12:55 AM, "Russell Bryant" <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>> wrote:<br>
>><br>
>> >Greetings,<br>
>> ><br>
>> >I'd like to check in on the status of this API addition:<br>
>> ><br>
>> > <a href="https://review.openstack.org/#/c/40692/" target="_blank">https://review.openstack.org/#/c/40692/</a><br>
>> ><br>
>> >The last comment is:<br>
>> ><br>
>> > "propose against stackforge as discussed at summit?"<br>
>> ><br>
>> >I don't see a session about this and from a quick look, don't see notes<br>
>> >related to it in other session etherpads.<br>
>> ><br>
>> >When was this discussed? Can you summarize it?<br>
>> ><br>
>> >Last I heard, this was just being deferred to be merged early in<br>
>> >Icehouse [1].<br>
>> ><br>
>> >This is blocking one of the most important security features for<br>
>> >OpenStack, IMO (trusted messaging) [2]. We've been talking about it<br>
>>for<br>
>> >years. Someone has finally made some real progress on it and I feel<br>
>> >like it has been given little to no attention.<br>
>> ><br>
>> >I'm not thrilled about the prospect of this going into a new project<br>
>>for<br>
>> >multiple reasons.<br>
>> ><br>
>> > - Given the priority and how long this has been dragging out, having<br>
>>to<br>
>> >wait for a new project to make its way into OpenStack is not very<br>
>> >appealing.<br>
>> ><br>
>> > - A new project needs to be able to stand on its own legs. It needs<br>
>>to<br>
>> >have a reasonably sized development team to make it sustainable. Is<br>
>> >this big enough for that?<br>
>> ><br>
>> >What's the thinking on this?<br>
>> ><br>
>> >[1]<br>
>><br>
>>><a href="http://lists.openstack.org/pipermail/openstack-dev/2013-August/013992.ht" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-August/013992.ht</a><br>
>>>ml<br>
>> >[2] <a href="https://review.openstack.org/#/c/37913/" target="_blank">https://review.openstack.org/#/c/37913/</a><br>
>> ><br>
>> >--<br>
>> >Russell Bryant<br>
>> ><br>
>> >_______________________________________________<br>
>> >OpenStack-dev mailing list<br>
>> ><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> ><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
><br>
>_______________________________________________<br>
>OpenStack-dev mailing list<br>
><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 33<br>
Date: Fri, 22 Nov 2013 12:13:17 -0500 (EST)<br>
From: Julie Pichon <<a href="mailto:jpichon@redhat.com">jpichon@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [horizon] Javascript development<br>
improvement<br>
Message-ID:<br>
<<a href="mailto:639410224.39211670.1385140397543.JavaMail.root@redhat.com">639410224.39211670.1385140397543.JavaMail.root@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
"Imre Farkas" <<a href="mailto:ifarkas@redhat.com">ifarkas@redhat.com</a>> wrote:<br>
> On 11/22/2013 02:49 PM, Maxime Vidori wrote:<br>
> >> It seems a bit crazy to me to introduce NodeJS as a dependency just for<br>
> >> the sake of an easy way to run jslint. There are other options<br>
> >> available that run without NodeJS as a dependency.<br>
> ><br>
> > Sadly, the only solutions which try to implement jslint in pure python are<br>
> > in alpha or abandoned. If you have a python library which has the same<br>
> > quality as jslint (which is written by Douglas Crockford himself), I will<br>
> > be glad to take a look at it.<br>
><br>
> There's a jslint fork called jshint which is able to run in the browser<br>
> without any node.js dependency.<br>
><br>
> I created a POC patch [1] long time ago to demonstrate its capabilities.<br>
> It's integrated with qunit and runs automatically with the horizon test<br>
> suite.<br>
<br>
Thanks Imre, this is interesting. Would you mind restoring the patch? If<br>
you don't have time to work on it please indicate so (I don't think it's<br>
possible to pick up a patch if the status is 'Abandoned') and someone else<br>
can look into the test failures.<br>
<br>
> The patch also contains a .jshintrc file for the node.js package but you<br>
> can remove it since it's not used by the qunit+jshint test at all.<br>
<br>
Sounds good.<br>
<br>
Julie<br>
<br>
> Imre<br>
><br>
> [1] <a href="https://review.openstack.org/#/c/41087/" target="_blank">https://review.openstack.org/#/c/41087/</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 34<br>
Date: Fri, 22 Nov 2013 10:26:36 -0700<br>
From: Carl Baldwin <<a href="mailto:carl@ecbaldwin.net">carl@ecbaldwin.net</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] L3 advanced features blueprint mapping to<br>
IETF and IEEE standards<br>
Message-ID:<br>
<CALiLy7qL9x7SBjkuazkHUJUg=muf2m1tLbomOP2NXw1eh20u=<a href="mailto:g@mail.gmail.com">g@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Nachi,<br>
<br>
I'm sorry to have missed this meeting. In my jet-lagged state, I<br>
somehow got it on my calendar for last night rather than last Tuesday<br>
night (my local time, MST). I have an interest in the dynamic routing<br>
area of neutron and I would like to be involved.<br>
<br>
Will this meeting be weekly? I'll go read through the meeting log.<br>
<br>
Carl Baldwin<br>
<br>
On Thu, Nov 7, 2013 at 11:18 PM, Nachi Ueno <<a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a>> wrote:<br>
> Hi folks<br>
><br>
> let's use #openstack-meeting on the meetings.<br>
><br>
> I have also created an etherpad for this discussion<br>
> (If you have any slide, please link to the page)<br>
><br>
> <a href="https://etherpad.openstack.org/p/NeutronDynamicRoutingIceHouse" target="_blank">https://etherpad.openstack.org/p/NeutronDynamicRoutingIceHouse</a><br>
><br>
> Best<br>
> Nachi<br>
><br>
><br>
><br>
> 2013/11/8 Pedro Roque Marques <<a href="mailto:pedro.r.marques@gmail.com">pedro.r.marques@gmail.com</a>>:<br>
>> What about an IRC meeting on this topic 11/19 at 9 p.m. PST ? This is 2 p.m<br>
>> in Japan and 6 a.m CET on the 20th.<br>
>> It is not ideal but i suspect we will have interest in participating from<br>
>> both Europe and Asia.<br>
>> I volunteer myself and Nachi Ueno <a href="mailto:nachi@ntti3.com">nachi@ntti3.com</a> (the author of the BGP<br>
>> MPLS blueprint) as agenda organizers; please drop us a note if you intend to<br>
>> attend and wether you would like to present something to the group.<br>
>><br>
>> Pedro.<br>
>><br>
>> On Nov 7, 2013, at 11:27 AM, Rochelle.Grober <<a href="mailto:Rochelle.Grober@huawei.com">Rochelle.Grober@huawei.com</a>><br>
>> wrote:<br>
>><br>
>><br>
>><br>
>> From: Pedro Roque Marques [mailto:<a href="mailto:pedro.r.marques@gmail.com">pedro.r.marques@gmail.com</a>]<br>
>> Colin,<br>
>> "The nice thing about standards is that there are so many of them to choose<br>
>> from."<br>
>><br>
>> For instance, if you take this Internet Draft:<br>
>> <a href="http://tools.ietf.org/html/draft-ietf-l3vpn-end-system-02" target="_blank">http://tools.ietf.org/html/draft-ietf-l3vpn-end-system-02</a> which is based on<br>
>> RFC4364.<br>
>><br>
>> It has already been implemented as a Neutron plugin via OpenContrail<br>
>> (<a href="http://juniper.github.io/contrail-vnc/README.html" target="_blank">http://juniper.github.io/contrail-vnc/README.html</a>); With this<br>
>> implementation each OpenStack cluster can be configured as its own<br>
>> Autonomous System.<br>
>><br>
>> There is a blueprint<br>
>> <a href="https://blueprints.launchpad.net/neutron/+spec/neutron-bgp-mpls-vpn" target="_blank">https://blueprints.launchpad.net/neutron/+spec/neutron-bgp-mpls-vpn</a><br>
>> that is discussing adding the provisioning of the autonomous system and<br>
>> peering to Neutron.<br>
>><br>
>> Please note that the work above does interoperate with 4364 using option B.<br>
>> Option C is possible but not that practical (as an operator you probably<br>
>> don't want to expose your internal topology between clusters).<br>
>><br>
>> If you want to give it a try you can use this devstack fork:<br>
>> <a href="https://github.com/dsetia/devstack" target="_blank">https://github.com/dsetia/devstack</a>.<br>
>> You can use it to interoperate with a standard router that implements 4364<br>
>> and support MPLS over GRE. Products from cisco/juniper/ALU/huwawei etc do.<br>
>><br>
>> I believe that the work i'm referencing implements interoperability while<br>
>> having very minimal changes to Neutron. It is based on the same concept of<br>
>> neutron virtual network and it hides the BGP/MPLS functionality from the<br>
>> user by translating policies that establish connectivity between virtual<br>
>> networks into RFC 4364 concepts.<br>
>> Please refer to:<br>
>> <a href="https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron" target="_blank">https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron</a><br>
>><br>
>> Would it make sense to have an IRC/Web meeting around interoperability with<br>
>> RFC4364 an OpenStack managed clusters ? I believe that there is a lot of<br>
>> work that has already been done there by multiple vendors as well as some<br>
>> carriers.<br>
>><br>
>> +1 And it should be scheduled and announced a reasonable time in advance<br>
>> developers can plan to participate.<br>
>><br>
>> --Rocky<br>
>><br>
>> Pedro.<br>
>><br>
>> On Nov 7, 2013, at 12:35 AM, Colin McNamara <<a href="mailto:colin@2cups.com">colin@2cups.com</a>> wrote:<br>
>><br>
>> I have a couple concerns that I don?t feel I clearly communicated during the<br>
>> L3 advanced features session. I?d like to take this opportunity to both<br>
>> clearly communicate my thoughts, as well as start a discussion around them.<br>
>><br>
>><br>
>> Building to the edge of the "autonomous system"<br>
>><br>
>> The current state of neutron implementation is functionally the l2 domain<br>
>> and simple l3 services that are part of a larger autonomous system. The<br>
>> routers and switches northbound of the OpenStack networking layer handled<br>
>> the abstraction and integration of the components.<br>
>><br>
>> Note, I use the term ?Autonomous System? to describe more then the notion of<br>
>> BGP AS, but more broadly in the term of a system that is controlled within a<br>
>> common framework and methodology, and integrates with a peer system that<br>
>> doesn?t not share that same scope or method of control<br>
>><br>
>> These components that composed the autonomous system boundary implement<br>
>> protocols and standards that map into IETF and IEEE standards. The reasoning<br>
>> for this is interoperability. Before vendors utilize IETF for<br>
>> interoperability at this layer, the provider experience was horrible (this<br>
>> was my personal experience in the late 90?s).<br>
>><br>
>><br>
>><br>
>> Wednesdays discussions in the Neutron Design Sessions<br>
>><br>
>> A couple of the discussions, most notably the extension of l3 functionality<br>
>> fell within the scope of starting the process of extending Neutron with<br>
>> functionality that will result (eventually) in the ability for an OpenStack<br>
>> installation to operate as it?s own Autonomous System.<br>
>><br>
>> The discussions that occurred to support L3 advanced functionality<br>
>> (northbound boundary), and the QOS extension functionality both fell into<br>
>> the scope of Northbound and Southbound boundaries of this system.<br>
>><br>
>> My comments in the session<br>
>><br>
>> My comments in the session, while clouded with jet-lag were specifically<br>
>> around two concepts that are used when integrating other types of systems<br>
>><br>
>> 1. In a simple (1-8) tenant environment integration with a northbound AS is<br>
>> normally done in a PE-CE model that generally centers around mapping dot1q<br>
>> tags into the appropriate northbound l3 segments and then handling the<br>
>> availability of the L2 path that traverses with port channeling, MLAG, STP,<br>
>> Etc.<br>
>><br>
>> 2. In a complex environment (8+ for discussion) different Carrier Supporting<br>
>> Carrier (CSC) methods defined in IETF RFC 4364 Section 10 type A, B or C are<br>
>> used. These allow the mapping of segregated tenant networks together and<br>
>> synchronizing between distributed systems. This normally extends the tagging<br>
>> or tunneling mechanism and then allows for BGP to synchronize NLRI<br>
>> information between AS?s.<br>
>><br>
>> These are the standard ways of integrating between carriers, but also<br>
>> components of these implementations are used to integrate and scale inside<br>
>> of a single web scale data center. Commonly when you scale beyond a certain<br>
>> physical port boundary (1000is edge ports in many implementations, much<br>
>> larger in current implementations) the same designs for C2C integrations are<br>
>> used to create network availability zones inside a web scale data center.<br>
>><br>
>> Support of these IETF and IEEE standard integrations are necessary for brown<br>
>> field installations<br>
>><br>
>> In a green field installation, diverging from IETF and IEEE standards on the<br>
>> north bound edge while not a great idea, can result in a functional<br>
>> implementation. In a brown field implementation where OpenStack Neutron will<br>
>> be integrated into an existing network core. This boundary layer is where we<br>
>> move from a controlled system into a distributed system. The cleanly<br>
>> integrate into this system, IETF and IEEE protocols and standards have to be<br>
>> followed.<br>
>><br>
>><br>
>><br>
>> <8DB71B56-CDE5-42D5-870E-CF94157510F8.png>When we diverge from this<br>
>> standards based integration at the north edge of our autonomous system we<br>
>> lose the ability to integrate without introducing major changes (and risk),<br>
>> into our core. In my experience this is sufficient to either slow or stall<br>
>> adoption. This is a major risk, that I believe can be mitigated.<br>
>><br>
>> My thoughts on mitigating this risk<br>
>><br>
>> We need to at least map and track the relevant IETF RFC?s that define the<br>
>> internet standards for integration at the AS boundary. I know that many of<br>
>> the network vendor developers that contribute to Neutron have access to<br>
>> people who both have deep knowledge of these standards, and also participate<br>
>> in the IETF working groups. I would hope that these resources could be<br>
>> leveraged to at least give a sanity check, at best ensure a compliant<br>
>> northbound interface to other systems.<br>
>><br>
>> Side benefit of engaging IETF members in this discussion<br>
>><br>
>> The other side benefit of this is that inventions inside of Neutron can also<br>
>> be communicated as standards to the rest of the world in the form of net new<br>
>> RFC?s. In OVS this has already happened, as OVS has emerged to be a common<br>
>> component in many network devices, and the need to establish and reference a<br>
>> common standard has risen it?s head. I would think that inventions within<br>
>> Neutron would follow this same path.<br>
>><br>
>><br>
>> Regards,<br>
>> Colin<br>
>> Colin McNamara<br>
>> People | Process | Technology<br>
>> --------------------------------------------<br>
>> Mobile: 858-208-8105<br>
>> Twitter: @colinmcnamara<br>
>> Linkedin: <a href="http://www.linkedin.com/colinmcnamara" target="_blank">www.linkedin.com/colinmcnamara</a><br>
>> Blog: <a href="http://www.colinmcnamara.com" target="_blank">www.colinmcnamara.com</a><br>
>> Email: <a href="mailto:colin@2cups.com">colin@2cups.com</a><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 35<br>
Date: Fri, 22 Nov 2013 12:36:12 -0500<br>
From: Doug Hellmann <<a href="mailto:doug.hellmann@dreamhost.com">doug.hellmann@dreamhost.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Cinder][Glance] OSLO update<br>
Message-ID:<br>
<<a href="mailto:CADb%2Bp3T0UuifbpywF22x-WTgjm8AzDJ58MG6VDQO8T2VzAWTvg@mail.gmail.com">CADb+p3T0UuifbpywF22x-WTgjm8AzDJ58MG6VDQO8T2VzAWTvg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
On Fri, Nov 22, 2013 at 11:21 AM, Duncan Thomas <<a href="mailto:duncan.thomas@gmail.com">duncan.thomas@gmail.com</a>>wrote:<br>
<br>
> On 22 November 2013 12:27, Elena Ezhova <<a href="mailto:eezhova@mirantis.com">eezhova@mirantis.com</a>> wrote:<br>
> > But what if I want to update some module that consists of ten or even<br>
> more<br>
> > files (like rpc or db) and each of these files has quite a long change<br>
> log?<br>
> > In that case the commit message may turn out to be really long even if<br>
> only<br>
> > commit ids and names are included.<br>
><br>
><br>
> A message that is too long is definitely a better problem to have than<br>
> a message that is missing important details.<br>
><br>
<br>
If we are talking about merging only part of oslo into a consuming project,<br>
then we can't just keep track of the "last" revision that was merged,<br>
because that won't necessarily include all of the changes. Elena, were you<br>
planning to keep a separate revision for each entry under openstack/common<br>
(not every file, just the files and directories at that level)?<br>
<br>
<br>
><br>
> To turn the question round, how can a reviewer review a change that<br>
> includes ten or even more files without any information on what<br>
> changed and why? rpc and db are extremely difficult imports to review,<br>
> and I've found problems in the last two I looked at.<br>
><br>
<br>
Problems in the code, or in the way the code was merged?<br>
<br>
Doug<br>
<br>
<br>
<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/ba060052/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/ba060052/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 36<br>
Date: Fri, 22 Nov 2013 17:39:00 +0000<br>
From: Tim Bell <<a href="mailto:Tim.Bell@cern.ch">Tim.Bell@cern.ch</a>><br>
To: "Daniel P. Berrange" <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>>, "OpenStack Development<br>
Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [nova] future fate of nova-network?<br>
Message-ID:<br>
<<a href="mailto:5D7F9996EA547448BC6C54C8C5AAF4E5D985259B@CERNXCHG02.cern.ch">5D7F9996EA547448BC6C54C8C5AAF4E5D985259B@CERNXCHG02.cern.ch</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Starting from the existing code also makes migration for production environments currently using the code much easier.<br>
<br>
Support those of us running production OpenStack clouds needs to be one of the major development concerns as people reflect on refactoring along with making sure we don't make OpenStack more difficult to install/manage/configure.<br>
<br>
Tim<br>
<br>
> -----Original Message-----<br>
> From: Daniel P. Berrange [mailto:<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>]<br>
> Sent: 22 November 2013 17:33<br>
> To: OpenStack Development Mailing List (not for usage questions)<br>
> Subject: Re: [openstack-dev] [nova] future fate of nova-network?<br>
><br>
> On Fri, Nov 22, 2013 at 11:24:18AM -0500, Russell Bryant wrote:<br>
> > On 11/22/2013 11:17 AM, Jonathan Proulx wrote:<br>
> > > To add to the screams of others removing features from nova-network<br>
> > > to achieve parity with neutron is a non starter, and it rather<br>
> > > scares me to hear it suggested.<br>
> ><br>
> > -1 from me too, so everyone can take a deep breath on this. :-)<br>
> ><br>
> > > Providing feature parity and easy cut over *should have been*<br>
> > > priority<br>
> > > 1 when quantum split out of nova as it was for cinder (which was a<br>
> > > delightful and completely unnoticable transition)<br>
> ><br>
> > +1<br>
> ><br>
> > I think the experience with Neutron provides us some very good insight<br>
> > for future project splits/replacements. We're working on establishing<br>
> > more clear requirements for project incubation and graduation in the TC.<br>
> > One note I put down was that we should require that projects stay<br>
> > completely focused on being able to deprecate their replacement before<br>
> > adding *anything* else whenever possible.<br>
> ><br>
> > A good example is the current discussion around a new scheduling<br>
> > service. There have been lots of big ideas around this. Robert<br>
> > Collins just started a thread about a proposal to start this project<br>
> > but with a very strict scope of being able to replace nova-scheduler,<br>
> > and *nothing* more until that's completely done. I like that approach quite a bit.<br>
><br>
> I'd suggest something even stronger. If we want to split out code into a new project, we should always follow the approach used for<br>
> cinder.<br>
> ie the existing fully functional code should be pulled out as is, and work then progress from there. That ensures we'd always have feature<br>
> parity from the very start. Yes, you might have to then do a large amount of refactoring to get to where you want to be, but IMHO that's<br>
> preferrable to starting something from scratch and forgetting to cover existing use cases.<br>
><br>
> Daniel<br>
> --<br>
> |: <a href="http://berrange.com" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
> |: <a href="http://libvirt.org" target="_blank">http://libvirt.org</a> -o- <a href="http://virt-manager.org" target="_blank">http://virt-manager.org</a> :|<br>
> |: <a href="http://autobuild.org" target="_blank">http://autobuild.org</a> -o- <a href="http://search.cpan.org/~danberr/" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
> |: <a href="http://entangle-photo.org" target="_blank">http://entangle-photo.org</a> -o- <a href="http://live.gnome.org/gtk-vnc" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 37<br>
Date: Fri, 22 Nov 2013 12:39:59 -0500<br>
From: Doug Hellmann <<a href="mailto:doug.hellmann@dreamhost.com">doug.hellmann@dreamhost.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Oslo] Improving oslo-incubator update.py<br>
Message-ID:<br>
<<a href="mailto:CADb%2Bp3Qy6qY%2B%2Biwdp5u9cVz06xOa-sQqegpRkui5fVPD8id3tQ@mail.gmail.com">CADb+p3Qy6qY++iwdp5u9cVz06xOa-sQqegpRkui5fVPD8id3tQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
On Fri, Nov 22, 2013 at 4:11 AM, Flavio Percoco <<a href="mailto:flavio@redhat.com">flavio@redhat.com</a>> wrote:<br>
<br>
> Greetings,<br>
><br>
> Based on the recent discussion that came out about not having enough<br>
> information in the commit message when syncing oslo-incubator modules,<br>
> I was thinking that besides encouraging people to write better commit<br>
> messages, we could also improve the script we use to sync those<br>
> modules.<br>
><br>
> Some of the changes that I've been thinking of:<br>
><br>
> 1) Store the commit sha from which the module was copied from.<br>
> Every project using oslo, currently keeps the list of modules it<br>
> is using in `openstack-modules.conf` in a `module` parameter. We<br>
> could store, along with the module name, the sha of the commit it<br>
> was last synced from:<br>
><br>
> module=log,commit<br>
><br>
> or<br>
><br>
> module=log<br>
> log=commit<br>
><br>
<br>
The second form will be easier to manage. Humans edit the module field and<br>
the script will edit the others.<br>
<br>
<br>
<br>
><br>
> 2) Add an 'auto-commit' parameter to the update script that will<br>
> generate a commit message with the short log of the commits where<br>
> the modules being updated were modified. Soemthing like:<br>
><br>
> Syncing oslo-incubator modules<br>
><br>
> log.py:<br>
> commit1: short-message<br>
> commit2: short-message<br>
> commit3: short-message<br>
><br>
> lockutils:<br>
> commit4: short-message<br>
> commit5: short-message<br>
><br>
> #1 will help with figuring out when was the last time a module was<br>
> updated and what changes have been introduced since then.<br>
><br>
> #2 won't be the recommended way for writing commit messages. Oslo<br>
> incubator syncs can have different side-effects in every project.<br>
> However, it could be useful for trivial syncs.<br>
><br>
<br>
It looks like #2 would be a good way to start with commit messages, and<br>
just leave it up to the person doing the merge to add the "why" information.<br>
<br>
Doug<br>
<br>
<br>
<br>
><br>
> Thoughts?<br>
><br>
> Cheers,<br>
> FF<br>
><br>
> --<br>
> @flaper87<br>
> Flavio Percoco<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/8c6e03c7/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/8c6e03c7/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 38<br>
Date: Fri, 22 Nov 2013 12:40:28 -0500<br>
From: Doug Hellmann <<a href="mailto:doug.hellmann@dreamhost.com">doug.hellmann@dreamhost.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Oslo] Improving oslo-incubator update.py<br>
Message-ID:<br>
<CADb+p3Q6-nywytb7VsaFNKZmGA=<a href="mailto:xYkiCaMEb4tM8OWCWoh726g@mail.gmail.com">xYkiCaMEb4tM8OWCWoh726g@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
On Fri, Nov 22, 2013 at 11:24 AM, Duncan Thomas <<a href="mailto:duncan.thomas@gmail.com">duncan.thomas@gmail.com</a>>wrote:<br>
<br>
> On 22 November 2013 14:59, Ben Nemec <<a href="mailto:openstack@nemebean.com">openstack@nemebean.com</a>> wrote:<br>
><br>
> > One other thought I had was to add the ability to split one Oslo sync up<br>
> > into multiple commits, either one per module, or even one per Oslo commit<br>
> > for some really large module changes (I'm thinking of the 1000 line db<br>
> sync<br>
> > someone mentioned recently). It would be more review churn, but at<br>
> least it<br>
> > would keep the changes per review down to a more reasonable level. I'm<br>
> not<br>
> > positive it would be beneficial, but I thought I'd mention it.<br>
><br>
> Cinder (often but not always me) tends to reject merges that do more<br>
> that one module at a time, because it makes it far harder to review<br>
> and spot problems, so some from of automation of this would be great.<br>
><br>
<br>
There are times when the commits are related, but in general this seems<br>
like a good practice.<br>
<br>
Doug<br>
<br>
<br>
<br>
><br>
> --<br>
> Duncan Thomas<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/6f52850e/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/6f52850e/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 39<br>
Date: Fri, 22 Nov 2013 12:46:17 -0500<br>
From: Doug Hellmann <<a href="mailto:doug.hellmann@dreamhost.com">doug.hellmann@dreamhost.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Ceilometer] meaning of resource_id in a<br>
meter<br>
Message-ID:<br>
<CADb+p3Qjdkz62aJ9rvh=GnahW=<a href="mailto:71cfa4maP-jDgh3tT6_GHEww@mail.gmail.com">71cfa4maP-jDgh3tT6_GHEww@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
On Thu, Nov 21, 2013 at 2:37 PM, Gordon Chung <<a href="mailto:chungg@ca.ibm.com">chungg@ca.ibm.com</a>> wrote:<br>
<br>
><br>
> > In all cases, these are free string fields. `user_id' and `project_id'<br>
> > map to Keystone _most of the time_,<br>
><br>
> i'm sort of torn between the two -- which is why i brought it up i guess.<br>
> i like the flexibility of having resource as a free string field but the<br>
> difference between resource and project/user fields is that we can query<br>
> directly on Resources. when we get a Resource, we get a list of associated<br>
> Meters and if we don't set resource_id in a consistent manner, i worry we<br>
> may be losing some relational information between Meters that groupings<br>
> based off consistent resource_id can provide.<br>
><br>
<br>
The tuple (project id, source, resource id) is expected to be unique so<br>
that those values combined with a specific meter provide useful information<br>
about the resource. Beyond that unique constraint, I'm not sure we apply<br>
any rules, although check the SQL schema to make sure the resource id field<br>
isn't a short VARCHAR.<br>
<br>
Doug<br>
<br>
<br>
<br>
><br>
> cheers,<br>
> gordon chung<br>
><br>
> openstack, ibm software standards<br>
> email: chungg [at] <a href="http://ca.ibm.com" target="_blank">ca.ibm.com</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/eefe680d/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/eefe680d/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 40<br>
Date: Fri, 22 Nov 2013 12:55:48 -0500<br>
From: Lorin Hochstein <<a href="mailto:lorin@nimbisservices.com">lorin@nimbisservices.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [nova] future fate of nova-network?<br>
Message-ID:<br>
<CADzpNMXD6Oc8C7d1zQXNS+_D8Of9QrEoe66_fCMffBgYrLE=<a href="mailto:2Q@mail.gmail.com">2Q@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
On Fri, Nov 22, 2013 at 12:39 PM, Tim Bell <<a href="mailto:Tim.Bell@cern.ch">Tim.Bell@cern.ch</a>> wrote:<br>
<br>
><br>
> Support those of us running production OpenStack clouds needs to be one of<br>
> the major development concerns as people reflect on refactoring along with<br>
> making sure we don't make OpenStack more difficult to<br>
> install/manage/configure.<br>
><br>
><br>
To that end, I recommend posting questions like "We're thinking of making<br>
large change 'X', how will that affect existing OpenStack deployments?" to<br>
the openstack-operators mailing list.<br>
<br>
I know there are several OpenStack operators who don't subscribe to<br>
openstack or openstack-dev lists because of the enormous traffic volume.<br>
<br>
Lorin<br>
<br>
--<br>
Lorin Hochstein<br>
Lead Architect - Cloud Services<br>
Nimbis Services, Inc.<br>
<a href="http://www.nimbisservices.com" target="_blank">www.nimbisservices.com</a><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/8d15a232/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/8d15a232/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 41<br>
Date: Fri, 22 Nov 2013 18:02:04 +0000<br>
From: "Daniel P. Berrange" <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] RFC: Potential to increase min required<br>
libvirt version to 0.9.11 ?<br>
Message-ID: <<a href="mailto:20131122180203.GL16339@redhat.com">20131122180203.GL16339@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
On Wed, Nov 20, 2013 at 04:02:02PM +0100, Ralf Haferkamp wrote:<br>
> On Wed, Nov 20, 2013 at 04:33:22PM +1300, Robert Collins wrote:<br>
> > On 20 November 2013 08:02, Daniel P. Berrange <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>> wrote:<br>
> > > Currently the Nova libvirt driver is declaring that it wants a minimum<br>
> > > of libvirt 0.9.6.<br>
> > ...<br>
> > > If there are other distros I've missed which expect to support deployment<br>
> > > of Icehouse please add them to this list. Hopefully there won't be any<br>
> > > with libvirt software older than Ubuntu 12.04 LTS....<br>
> > ><br>
> > ><br>
> > > The reason I'm asking this now, is that we're working to make the libvirt<br>
> > > python module a separate tar.gz that can build with multiple libvirt<br>
> > > versions, and I need to decide how ancient a libvirt we should support<br>
> > > for it.<br>
> ><br>
> > Fantastic!!!<br>
> ><br>
> > The Ubuntu cloud archive<br>
> > <a href="https://wiki.ubuntu.com/ServerTeam/CloudArchive" target="_blank">https://wiki.ubuntu.com/ServerTeam/CloudArchive</a> is how OpenStack is<br>
> > delivered by Canonical for Ubuntu LTS users. So I think you can go<br>
> > with e.g. 0.9.11 or even 0.9.12 depending on what the Suse folk say.<br>
> I think 0.9.11 is fine for us. I am not worried too much about 0.9.12 either<br>
> since openSUSE 12.2 (which has 0.9.11) will reach its EOL soon. I also added<br>
> SLES to the table on:<br>
> <a href="https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix" target="_blank">https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix</a><br>
<br>
Thanks, it looks like from the libvirt side, we are only going to be<br>
able to provide a standalone libvirt-python on PyPI that works<br>
back to version 0.9.11. Prior to 0.9.11 libvirt did not install its<br>
API description, which is a pre-requisite for the python bindings<br>
to build.<br>
<br>
Fortunately 0.9.11 lines up with all the distros we've got listed<br>
so far.<br>
<br>
Daniel<br>
--<br>
|: <a href="http://berrange.com" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" target="_blank">http://libvirt.org</a> -o- <a href="http://virt-manager.org" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" target="_blank">http://autobuild.org</a> -o- <a href="http://search.cpan.org/~danberr/" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" target="_blank">http://entangle-photo.org</a> -o- <a href="http://live.gnome.org/gtk-vnc" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 42<br>
Date: Fri, 22 Nov 2013 18:15:40 +0000<br>
From: "Daniel P. Berrange" <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>><br>
To: Lorin Hochstein <<a href="mailto:lorin@nimbisservices.com">lorin@nimbisservices.com</a>><br>
Cc: "OpenStack Development Mailing List \(not for usage questions\)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [nova] future fate of nova-network?<br>
Message-ID: <<a href="mailto:20131122181540.GN16339@redhat.com">20131122181540.GN16339@redhat.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
On Fri, Nov 22, 2013 at 12:55:48PM -0500, Lorin Hochstein wrote:<br>
> On Fri, Nov 22, 2013 at 12:39 PM, Tim Bell <<a href="mailto:Tim.Bell@cern.ch">Tim.Bell@cern.ch</a>> wrote:<br>
><br>
> ><br>
> > Support those of us running production OpenStack clouds needs to be one of<br>
> > the major development concerns as people reflect on refactoring along with<br>
> > making sure we don't make OpenStack more difficult to<br>
> > install/manage/configure.<br>
> ><br>
> ><br>
> To that end, I recommend posting questions like "We're thinking of making<br>
> large change 'X', how will that affect existing OpenStack deployments?" to<br>
> the openstack-operators mailing list.<br>
><br>
> I know there are several OpenStack operators who don't subscribe to<br>
> openstack or openstack-dev lists because of the enormous traffic volume.<br>
<br>
That's a good point, I should have asked that list about the proposal<br>
to increase the min required libvirt version too. I've posted to it now...<br>
<br>
Daniel<br>
--<br>
|: <a href="http://berrange.com" target="_blank">http://berrange.com</a> -o- <a href="http://www.flickr.com/photos/dberrange/" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" target="_blank">http://libvirt.org</a> -o- <a href="http://virt-manager.org" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" target="_blank">http://autobuild.org</a> -o- <a href="http://search.cpan.org/~danberr/" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" target="_blank">http://entangle-photo.org</a> -o- <a href="http://live.gnome.org/gtk-vnc" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 43<br>
Date: Fri, 22 Nov 2013 13:22:12 -0500<br>
From: Jordan OMara <<a href="mailto:jomara@redhat.com">jomara@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [horizon] Javascript development<br>
improvement<br>
Message-ID: <<a href="mailto:20131122182212.GC1565@redhat.com">20131122182212.GC1565@redhat.com</a>><br>
Content-Type: text/plain; charset="us-ascii"; Format="flowed"<br>
<br>
On 22/11/13 12:06 -0500, Julie Pichon wrote:<br>
>I don't think Selenium is going away, and efforts have started around<br>
>using it as well for our integration tests [0]. Looking at the current<br>
>AngularJS patch up for review, it is testable without requiring<br>
>NodeJS.<br>
<br>
While the Angular modules are testable in QUnit, it would be a boon to use the<br>
testing patterns common with most Angular projects. It would make new<br>
developers, familiar with Angular but not Horizon, immediately familiar with the<br>
workflow.<br>
<br>
QUnit is acceptable, but karma/jasmine is preferable<br>
<br>
> From the initial mailing list discussion [1], my understanding<br>
>is that we're planning on using a specific AngularJS feature, not<br>
>rewriting everything with it. Changing our build system to accommodate<br>
>this seems like getting a bit ahead of ourselves.<br>
><br>
>[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-November/018850.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-November/018850.html</a><br>
<br>
To be clear, we're using a specific feature of Angular (the directive) to<br>
introduce it into the existing Django templates; that's not the only feature of<br>
Angular we're using. There are controllers & services behind the directive, but<br>
using a directive is the cleanest way of integrating these features with the<br>
existing templates.<br>
<br>
--<br>
Jordan O'Mara <jomara at <a href="http://redhat.com" target="_blank">redhat.com</a>><br>
Red Hat Engineering, Raleigh<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: not available<br>
Type: application/pgp-signature<br>
Size: 490 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/ff4e2553/attachment-0001.pgp" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/ff4e2553/attachment-0001.pgp</a>><br>
<br>
------------------------------<br>
<br>
Message: 44<br>
Date: Fri, 22 Nov 2013 13:26:13 -0500<br>
From: Eric Windisch <<a href="mailto:eric@cloudscaling.com">eric@cloudscaling.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Introducing the new OpenStack service for<br>
Containers<br>
Message-ID:<br>
<<a href="mailto:CALnZm-am%2BJ_ospzKCw8VZcTsMSm3ASP7HH4hxtJvPCHfiCfSbw@mail.gmail.com">CALnZm-am+J_ospzKCw8VZcTsMSm3ASP7HH4hxtJvPCHfiCfSbw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On Fri, Nov 22, 2013 at 11:49 AM, Krishna Raman <<a href="mailto:kraman@gmail.com">kraman@gmail.com</a>> wrote:<br>
> Reminder: We are meting in about 15 minutes on #openstack-meeting channel.<br>
<br>
I wasn't able to make it. Was meeting-bot triggered? Is there a log of<br>
today's discussion?<br>
<br>
Thank you,<br>
Eric Windisch<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 45<br>
Date: Fri, 22 Nov 2013 18:49:09 +0000<br>
From: Mark McLoughlin <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Keystone][Oslo] Future of Key<br>
Distribution Server, Trusted Messaging<br>
Message-ID: <1385146149.4314.14.camel@sorcha><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
On Fri, 2013-11-22 at 11:04 +0100, Thierry Carrez wrote:<br>
> Russell Bryant wrote:<br>
> > [...]<br>
> > I'm not thrilled about the prospect of this going into a new project for<br>
> > multiple reasons.<br>
> ><br>
> > - Given the priority and how long this has been dragging out, having to<br>
> > wait for a new project to make its way into OpenStack is not very appealing.<br>
> ><br>
> > - A new project needs to be able to stand on its own legs. It needs to<br>
> > have a reasonably sized development team to make it sustainable. Is<br>
> > this big enough for that?<br>
><br>
> Having it in Barbican (and maybe have Barbican join under the identity<br>
> program) would mitigate the second issue. But the first issue stands,<br>
> and I share your concerns.<br>
<br>
Yes, I agree. It's disappointing that this change of plans looks like<br>
its going to push out the ability of an OpenStack deployment to be<br>
secured.<br>
<br>
If this becomes a Barbican API, then we might be able to get the code<br>
working quickly ... but it will still be some time before Barbican is an<br>
integrated project, and so securing OpenStack will only be possible if<br>
you use this non-integrated project.<br>
<br>
Mark.<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 46<br>
Date: Fri, 22 Nov 2013 19:07:39 +0000<br>
From: "Yathiraj Udupi (yudupi)" <<a href="mailto:yudupi@cisco.com">yudupi@cisco.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a<br>
modest proposal for an external scheduler in our lifetime<br>
Message-ID: <<a href="mailto:CEB4E9FC.22073%25yudupi@cisco.com">CEB4E9FC.22073%yudupi@cisco.com</a>><br>
Content-Type: text/plain; charset="Windows-1252"<br>
<br>
I would definitely like to take part in this discussion and also<br>
contribute where I can. I was part of the scheduler sessions in the<br>
recent summit along with Debo Dutta, Gary Kotton, and Mike Spreitzer and<br>
we had proposed sessions on smart resource placement, and also the<br>
instance group API work for nova. We have been discussing this at our<br>
weekly scheduler meetings as well.<br>
I am also in the process of contributing a Solver Scheduler - a<br>
constraints-solver based way of finding optimal resource placements in<br>
openstack.<br>
In our smart resource placement proposal, we discussed a high level<br>
overview of scheduling considering cross services, and it hints at how the<br>
scheduler should sit outside as a separate service. But we decided to<br>
start within Nova first.<br>
<br>
This work of separating the scheduler is very promising, and I definitely<br>
would like to be involved in this effort.<br>
<br>
Thanks,<br>
Yathi.<br>
<br>
?<br>
<br>
On 11/21/13, 12:58 PM, "Robert Collins" <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<br>
<br>
><a href="https://etherpad.openstack.org/p/icehouse-external-scheduler" target="_blank">https://etherpad.openstack.org/p/icehouse-external-scheduler</a><br>
><br>
>I'm looking for 4-5 folk who have:<br>
> - modest Nova skills<br>
> - time to follow a fairly mechanical (but careful and detailed work<br>
>needed) plan to break the status quo around scheduler extraction<br>
><br>
>And of course, discussion galore about the idea :)<br>
><br>
>Cheers,<br>
>Rob<br>
><br>
>--<br>
>Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
>Distinguished Technologist<br>
>HP Converged Cloud<br>
><br>
>_______________________________________________<br>
>OpenStack-dev mailing list<br>
><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 47<br>
Date: Sat, 23 Nov 2013 00:44:16 +0530<br>
From: Rohan Kanade <<a href="mailto:openstack@rohankanade.com">openstack@rohankanade.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] [Ironic][Cinder] Attaching Cinder volumes to<br>
baremetal instance<br>
Message-ID:<br>
<<a href="mailto:CAH3Sreo1C4-a72Kb%2BhaUrzkZ7Zr2UY%2BMCmppJfaEDgQR4UG7wQ@mail.gmail.com">CAH3Sreo1C4-a72Kb+haUrzkZ7Zr2UY+MCmppJfaEDgQR4UG7wQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hey guys, just starting out with Ironic, had a silly question.<br>
<br>
Can we attach bootable or non bootable plain cinder volumes during either<br>
provisioning of the baremetal instance or after provisioning the baremetal<br>
instance?<br>
<br>
I have seen a "attach_volume" method in the "LibvirtVolumeDriver" of the<br>
nova baremetal driver. So got curious.<br>
<br>
Thanks,<br>
Rohan Kanade<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131123/5565ea0b/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131123/5565ea0b/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 48<br>
Date: Fri, 22 Nov 2013 11:29:24 -0800<br>
From: Krishna Raman <<a href="mailto:kraman@gmail.com">kraman@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] Introducing the new OpenStack service for<br>
Containers<br>
Message-ID: <<a href="mailto:81B1D424-5508-4A18-8F09-0DCED1A4CE3A@gmail.com">81B1D424-5508-4A18-8F09-0DCED1A4CE3A@gmail.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
<br>
On Nov 22, 2013, at 10:26 AM, Eric Windisch <<a href="mailto:eric@cloudscaling.com">eric@cloudscaling.com</a>> wrote:<br>
<br>
> On Fri, Nov 22, 2013 at 11:49 AM, Krishna Raman <<a href="mailto:kraman@gmail.com">kraman@gmail.com</a>> wrote:<br>
>> Reminder: We are meting in about 15 minutes on #openstack-meeting channel.<br>
><br>
> I wasn't able to make it. Was meeting-bot triggered? Is there a log of<br>
> today's discussion?<br>
<br>
Yes. Logs are here: <a href="http://eavesdrop.openstack.org/meetings/nova/2013/nova.2013-11-22-17.01.log.html" target="_blank">http://eavesdrop.openstack.org/meetings/nova/2013/nova.2013-11-22-17.01.log.html</a><br>
<br>
><br>
> Thank you,<br>
> Eric Windisch<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/a7281201/attachment-0001.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20131122/a7281201/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 49<br>
Date: Fri, 22 Nov 2013 19:43:05 +0000<br>
From: Jeremy Stanley <<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [Nova] [Infra] Support for PCI<br>
Passthrough<br>
Message-ID: <<a href="mailto:20131122194303.GP2304@yuggoth.org">20131122194303.GP2304@yuggoth.org</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On 2013-11-22 08:59:16 +0000 (+0000), Tan, Lin wrote:<br>
[...]<br>
> Our module only works on the compute node that enables VT-d and<br>
> contains special PCIs which support the SR-IOV.<br>
><br>
> So is it possible to<br>
><br>
> 1. setup compute node which enables pci passthrough.<br>
><br>
> 2. modify the testing schedule logic allow the pci testing case<br>
> be scheduled to that machine<br>
[...]<br>
<br>
If you're asking about our official test infrastructure for the<br>
OpenStack project, I believe this is infeasible for now. We<br>
currently perform testing within generic virtual machines provided<br>
by HPCloud and Rackspace, so the Nova compute nodes we build and<br>
test are already running under virtualization and in turn manage<br>
only paravirtualized QEMU instances.<br>
<br>
In the near term, your best bet is to run your own test<br>
infrastructure supporting the hardware features you require and<br>
report advisory results back on proposed changes:<br>
<br>
<a href="http://ci.openstack.org/third_party.html" target="_blank">http://ci.openstack.org/third_party.html</a><br>
<br>
For a longer term solution, you may want to consult with the TripleO<br>
project with regards to their bare-metal test plan:<br>
<br>
<a href="https://wiki.openstack.org/wiki/TripleO/TripleOCloud" target="_blank">https://wiki.openstack.org/wiki/TripleO/TripleOCloud</a><br>
<br>
--<br>
Jeremy Stanley<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 50<br>
Date: Fri, 22 Nov 2013 20:50:44 +0100 (CET)<br>
From: Maxime Vidori <<a href="mailto:maxime.vidori@enovance.com">maxime.vidori@enovance.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [horizon] Javascript development<br>
improvement<br>
Message-ID:<br>
<<a href="mailto:1734467249.1771409.1385149844843.JavaMail.root@enovance.com">1734467249.1771409.1385149844843.JavaMail.root@enovance.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
That is a fact all client side development is based on javascript, Node allow us to easily execute javascript without a browser. Every time we will have a reflexion on the client side, Node will show up, what we are doing is just delaying something inevitable and wasting our forces in compromises. Node is not the best way, but it is the easiest one, what would we do next time, search another alternative in python, if it is buggy we will have to maintain it. You are right Node is currently fancy, but less is fancy, angular is fancy but they provides some ease and that is why we choose them.<br>
<br>
----- Original Message -----<br>
From: "Jordan OMara" <<a href="mailto:jomara@redhat.com">jomara@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
Sent: Friday, November 22, 2013 7:22:12 PM<br>
Subject: Re: [openstack-dev] [horizon] Javascript development improvement<br>
<br>
On 22/11/13 12:06 -0500, Julie Pichon wrote:<br>
>I don't think Selenium is going away, and efforts have started around<br>
>using it as well for our integration tests [0]. Looking at the current<br>
>AngularJS patch up for review, it is testable without requiring<br>
>NodeJS.<br>
<br>
While the Angular modules are testable in QUnit, it would be a boon to use the<br>
testing patterns common with most Angular projects. It would make new<br>
developers, familiar with Angular but not Horizon, immediately familiar with the<br>
workflow.<br>
<br>
QUnit is acceptable, but karma/jasmine is preferable<br>
<br>
> From the initial mailing list discussion [1], my understanding<br>
>is that we're planning on using a specific AngularJS feature, not<br>
>rewriting everything with it. Changing our build system to accommodate<br>
>this seems like getting a bit ahead of ourselves.<br>
><br>
>[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-November/018850.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-November/018850.html</a><br>
<br>
To be clear, we're using a specific feature of Angular (the directive) to<br>
introduce it into the existing Django templates; that's not the only feature of<br>
Angular we're using. There are controllers & services behind the directive, but<br>
using a directive is the cleanest way of integrating these features with the<br>
existing templates.<br>
<br>
--<br>
Jordan O'Mara <jomara at <a href="http://redhat.com" target="_blank">redhat.com</a>><br>
Red Hat Engineering, Raleigh<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 51<br>
Date: Fri, 22 Nov 2013 20:03:20 +0000<br>
From: Jeremy Stanley <<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] How to stage client major releases in<br>
Gerrit?<br>
Message-ID: <<a href="mailto:20131122200320.GQ2304@yuggoth.org">20131122200320.GQ2304@yuggoth.org</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On 2013-11-22 10:34:40 +0100 (+0100), Thierry Carrez wrote:<br>
> It can be created on request by release management members (or<br>
> infra-core team). I /think/ that by default it would get tested against<br>
> master in other branches.<br>
<br>
More details at...<br>
<br>
<URL: <a href="https://wiki.openstack.org/wiki/GerritJenkinsGithub#Merge_Commits" target="_blank">https://wiki.openstack.org/wiki/GerritJenkinsGithub#Merge_Commits</a> ><br>
<br>
--<br>
Jeremy Stanley<br>
<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
End of OpenStack-dev Digest, Vol 19, Issue 66<br>
*********************************************<br>
</blockquote></div><br></div>