Re: [Openstack] POC for Pluggable Network Service
Just wanted to say thank you for putting together an excellent spec document. Thanks, jay 2011/3/31 石井 久治 ishii.hisah...@lab.ntt.co.jp: Hi Everyone, I have implemented a POC code for Pluggable Network Service at lp:~ntt-pf-lab/nova/network-service. And wrote the document of it http://wiki.openstack.org/NetworkServicePOC This document outlines the new network architecture for Nova that I would like to propose for the Diablo release. This is just a first draft, so I would love to get some feedbacks from the community to discuss and improve it. And hopefully attract some willing participants as well! Thanks, Hisaharu Ishii ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] installing Nova in the Cloud
I would like to install Open Stack Nova in few servers in the cloud. Is this possible? Which version? Any specific Cloud provider recommendations? Thanks, Nelson Nahum nel...@zadarastorage.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] installing Nova in the Cloud
Hi Nelson, we have successfully deployed a multinode installation of Nova with our distro Stackops on a VMware ESXi 4.1. QEMU is the only available emulator when running on top of a hypervisor. I guess you can use our distro to deploy on any Cloud Provider that allows you to upload an ISO image and install it on several virtual machines. As far as I know you can install ISOs in Terremark vCloud Express, and they use VMware as the hypervisor. We use FlatDHCP as the network model. You can download the distro from http://www.stackops.org Let us know if it works, -- Diego Parrilla CEO www.stackops.com | diego.parri...@stackops.com | +34 649 94 43 29 | skype:diegoparrilla ADVERTENCIA LEGAL Le informamos, como destinatario de este mensaje, que el correo electrónico y las comunicaciones por medio de Internet no permiten asegurar ni garantizar la confidencialidad de los mensajes transmitidos, así como tampoco su integridad o su correcta recepción, por lo que STACKOPS TECHNOLOGIES S.L. no asume responsabilidad alguna por tales circunstancias. Si no consintiese en la utilización del correo electrónico o de las comunicaciones vía Internet le rogamos nos lo comunique y ponga en nuestro conocimiento de manera inmediata. Este mensaje va dirigido, de manera exclusiva, a su destinatario y contiene información confidencial y sujeta al secreto profesional, cuya divulgación no está permitida por la ley. En caso de haber recibido este mensaje por error, le rogamos que, de forma inmediata, nos lo comunique mediante correo electrónico remitido a nuestra atención y proceda a su eliminación, así como a la de cualquier documento adjunto al mismo. Asimismo, le comunicamos que la distribución, copia o utilización de este mensaje, o de cualquier documento adjunto al mismo, cualquiera que fuera su finalidad, están prohibidas por la ley. * PRIVILEGED AND CONFIDENTIAL We hereby inform you, as addressee of this message, that e-mail and Internet do not guarantee the confidentiality, nor the completeness or proper reception of the messages sent and, thus, STACKOPS TECHNOLOGIES S.L. does not assume any liability for those circumstances. Should you not agree to the use of e-mail or to communications via Internet, you are kindly requested to notify us immediately. This message is intended exclusively for the person to whom it is addressed and contains privileged and confidential information protected from disclosure by law. If you are not the addressee indicated in this message, you should immediately delete it and any attachments and notify the sender by reply e-mail. In such case, you are hereby notified that any dissemination, distribution, copying or use of this message or any attachments, for any purpose, is strictly prohibited by law. On Thu, Mar 31, 2011 at 6:57 PM, Nelson Nahum nel...@zadarastorage.com wrote: I would like to install Open Stack Nova in few servers in the cloud. Is this possible? Which version? Any specific Cloud provider recommendations? Thanks, Nelson Nahum nel...@zadarastorage.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] installing Nova in the Cloud
On Thu, 31 Mar 2011 09:57:03 -0700 Nelson Nahum nel...@zadarastorage.com wrote: I would like to install Open Stack Nova in few servers in the cloud. Is this possible? Which version? Any specific Cloud provider recommendations? Thanks, Nelson Nahum nel...@zadarastorage.com Hi, I recently installed openstack on an m1.large ec2 instance using openstack and LXC recently for testing purposes. You'll need to get the latestest trunk and the latest natty EC2 images and the latest Natty UEC images as well. Regards chuck ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] POC for Pluggable Network Service
I second the comment about a great spec. I look forward to poking at this and working with you to incorporate feedback. After a quick pass, I think the work we have done with the network-service should play well within your model. Dan 2011/3/31 Jay Pipes jaypi...@gmail.com Just wanted to say thank you for putting together an excellent spec document. Thanks, jay 2011/3/31 石井 久治 ishii.hisah...@lab.ntt.co.jp: Hi Everyone, I have implemented a POC code for Pluggable Network Service at lp:~ntt-pf-lab/nova/network-service. And wrote the document of it http://wiki.openstack.org/NetworkServicePOC This document outlines the new network architecture for Nova that I would like to propose for the Diablo release. This is just a first draft, so I would love to get some feedbacks from the community to discuss and improve it. And hopefully attract some willing participants as well! Thanks, Hisaharu Ishii ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- ~~~ Dan Wendlandt Nicira Networks, Inc. www.nicira.com | www.openvswitch.org cell: 650-906-2650 ~~~ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] installing Nova in the Cloud
Do you have a public image? It would be handy for those of us that have infrastructure on EC2 to be able to spin up test servers. Brian Schott bfsch...@gmail.com On Mar 31, 2011, at 1:33 PM, Chuck Short wrote: On Thu, 31 Mar 2011 09:57:03 -0700 Nelson Nahum nel...@zadarastorage.com wrote: I would like to install Open Stack Nova in few servers in the cloud. Is this possible? Which version? Any specific Cloud provider recommendations? Thanks, Nelson Nahum nel...@zadarastorage.com Hi, I recently installed openstack on an m1.large ec2 instance using openstack and LXC recently for testing purposes. You'll need to get the latestest trunk and the latest natty EC2 images and the latest Natty UEC images as well. Regards chuck ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Search API
To diagnose issues in a production system, administrators may at times need to find a server or host based on limited information. I've proposed a blueprint for a generic search API with wildcard support to handle this need; I'm curious to learn if others also see that need, or if there are existing Nova features that would meet the need. https://blueprints.launchpad.net/nova/+spec/search-api [cid:5C3A53C1-541B-4A0B-9FF1-DCA54F2A4BDA] Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. inline: signature[2].png___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal to defer existing OS API v1.1 to Diablo, for greater stability in Cactus
On Wednesday, March 30, 2011 6:16pm, Rick Clark r...@openstack.org said: ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp On 03/30/2011 04:54 PM, Justin Santa Barbara wrote: I would like to propose a fallback scenario for Cactus release management purposes, which would free up Titan resources and get us a better, more stable API with greater client support: - We defer any non-essential changes in the V1.1 API to post-Cactus. - We can then discuss these thoroughly at the design summit (I do not believe we had a design summit discussion on these API changes, for timing reasons) - We make the V1.1 API a minimal extension to V1.0, to support the Cactus features we're going to ship. For example, Brian Waldon pointed out that we would need a new element for the changePassword action, and for extensions also. - These minimal differences would be driven by the people that need them (primarily the Titan team) I am confident they're not going to be introducing things that are not strictly necessary at this stage of the game :-) - We may have to postpone extensions that inject additional content into existing elements, and stick to extensions that extend the URI space, so that the XML schema for V1.1 is minimal. Extension of existing elements probably warrants a Design Summit discussion anyway. We do not yet have any (non-test) extensions that inject content. - We would rename the current V1.1 API to V1.2 or V2.0 - we are just deferring it to Diablo, not abandoning it. - We could still ship the renamed API as experimental, even in Cactus - The goal is to focus resources on one API that will then work 100%. - Yes, it's still sort of going to be two APIs, but if we're really lucky we might get away with almost no 'switching' code. For example, if we _add_ a URI or an action, a V1.0 client will never discover it. - In particular, we want to avoid the output format changing between versions wherever we can. - I hope by virtue of this approach that Cactus will be 100% compatible with existing v1.0 (CloudServers) clients - I hope also that V1.0 clients can just switch to use the V1.1 endpoint when they're ready, and need make code changes only for things which have actually changed. I believe this is entirely in line with our goals for Cactus. I am less confident that the current V1.1 API is in line with our Cactus goals. Thoughts? Anyone from the Titan team want to comment on how they feel about the timetable for delivering the APIs in Cactus? ttx? I 100% agree. The 1.1 specs were handed over far too late for it to be reasonable to get the work done in Cactus. I am amazed at what the titan team has accomplished. I think that rackspace feels *very* strongly about getting the 1.1 done, though. John Purrier can answer that. Justin ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp So first, I apologize that it hasn't been easy to see the exact state of the 1.0 and 1.1 APIs in an easy way. I'd start by giving an update on where those two versions of the APIs stand. API v1.0: The guys on titan and ozone did a lot of work to bring this very close to spec this release, and it is much more usable than it was prior to cactus. There are already some bugs filed on this (the largest one I know of off the top of my head is that rebuild is not supported - Brians Lamar and Waldon are close to completing this). Missing Features: - Shared IP Groups - Scheduled Backups I think these are relatively minor in the scheme of things, but I leave that to you to decide. The biggest gap in my mind is the difference between the spec and implementation in terms of the XML format. We have discussed a few ways to deal with this in IRC and locally, but by and large I think this is something too big to make it into cactus, whichever route we take. The fix is in coming up with a sane serialization mechanism; someone on titan will file a blueprint about this very soon. API v1.1: Again, we got pretty close on this as well. Missing Features - Affinity ID - IPv6 Support at the OS API level Again, the format of data is the big gap. In this case, the json is closer to the 1.0 style rather than the 1.1 style. In addition, the XML data still suffers the same problems that 1.0 suffers from. Given this, what makes the most sense to me is to focus on stability for version 1.0 API excluding XML support. The bindings that are out there have strong support for the JSON data
Re: [Openstack] installing Nova in the Cloud
Thanks Diego and Chuck, I will try those. Nelson On Thu, Mar 31, 2011 at 10:33 AM, Chuck Short chuck.sh...@canonical.comwrote: On Thu, 31 Mar 2011 09:57:03 -0700 Nelson Nahum nel...@zadarastorage.com wrote: I would like to install Open Stack Nova in few servers in the cloud. Is this possible? Which version? Any specific Cloud provider recommendations? Thanks, Nelson Nahum nel...@zadarastorage.com Hi, I recently installed openstack on an m1.large ec2 instance using openstack and LXC recently for testing purposes. You'll need to get the latestest trunk and the latest natty EC2 images and the latest Natty UEC images as well. Regards chuck ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Feature Freeze status
I'm gonna +1 Todd. Actually, apache server has a great dev process. They have goals for releases, but people are welcome to submit patches to their mailing list any time, get comments on them, then they're merged if and when people vote them as ready. -- Mike ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Feature Freeze status
On Thu, Mar 31, 2011 at 5:21 PM, Michael Barton mike-launch...@weirdlooking.com wrote: I'm gonna +1 Todd. Actually, apache server has a great dev process. They have goals for releases, but people are welcome to submit patches to their mailing list any time, get comments on them, then they're merged if and when people vote them as ready. We're talking about prioritizing the merge proposals that pile up based on whether such public discussion has occurred on the ML and/or has been documented on a blueprint. We're not talking about limiting people's ability to submit patches. We're talking about prioritizing the reviews that have been proposed... -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Feature Freeze status
There has been a lot of great discussion and airing-out around blueprint and merge process. I think some good points have been raised on all sides. I'd like to weigh in with some perspective-changing suggestions about how we can manage specs and blueprints that I think everyone will be happy with. Basically we are all in the process of learning how to manage a large open-source project with 100+ developers, and I think managing a group that large by throwing everyone into a pool and hoping that all of the developers can collaborate effectively is a bit optimistic. The suggestions that I outline below are not radical changes from how we are currently doing things, but hopefully it will help clarify the process. Blueprints People have extolled the value of blueprints many times, and I agree that they are very valuable. But I think blueprints are much more valuable from a project management perspective than they are from an 'in-the-weeds' coding perspective. I would suggest that blueprints are used to give a broad overview of an intended feature and enough technical information for the PTL and other teams to ensure that work isn't being duplicated. Since we all work in teams, I think it is reasonable to expect every team to have a contact person that is responsible for ensuring that the team's blueprints are up-to-date with what they are actually working on. Internal to the team this can be managed however they see fit. It can be offloaded to individual developers or handled by a project manager, etc. If we can all strive to follow this limited use of blueprints, I think it gives us the advantages that they provide for project management without putting too much strain on the developers. Specs Detailed specs beyond a brief technical overview should not be required in all cases. It is strongly recommended (but not required) for a team to make available any internal specifications that they are using. For small features, a simple link to a public branch is enough. Detailed Specs should be required in the following cases: * A large feature that touches a lot of the code * Code that will need multiple merge proposals * Features that are being worked on by multiple teams * A feature that is blocking features by other teams. I think we could Branches Teams should be encouraged to keep their branches in the public as work goes on. This allows curious community members to drill down into the current development and see what is going on. This is especially important for teams using agile development. Merge Merges should be evaluated on merit. If we get a large feature without an associated blueprint/spec, we can help educate the developer on the blueprint / spec process, but i don't think we should block merging if the feature is well designed and tested. Obviously if the feature interferes with other blueprints in the pipeline, we can block it. In conclusion, I strongly agree with soren's comment that the core developers should be following the suggested process, and I will mea culpa in my own avoidance of blueprints. I think a lot of the issues the developers have had are due to a feeling that it is a) complicated and b) not valuable. Hopefully with the understanding of the value that has been provided in this thread and the clarification and suggestions I've provided, we can all improve our teamwork. Please let me know if I've missed anything. Vish___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Feature Freeze status
Well said. I don't disagree with any of your points or suggestions below. Looking forward to a productive chat about it at the summit in a few weeks. -jay On Thu, Mar 31, 2011 at 6:09 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: There has been a lot of great discussion and airing-out around blueprint and merge process. I think some good points have been raised on all sides. I'd like to weigh in with some perspective-changing suggestions about how we can manage specs and blueprints that I think everyone will be happy with. Basically we are all in the process of learning how to manage a large open-source project with 100+ developers, and I think managing a group that large by throwing everyone into a pool and hoping that all of the developers can collaborate effectively is a bit optimistic. The suggestions that I outline below are not radical changes from how we are currently doing things, but hopefully it will help clarify the process. Blueprints People have extolled the value of blueprints many times, and I agree that they are very valuable. But I think blueprints are much more valuable from a project management perspective than they are from an 'in-the-weeds' coding perspective. I would suggest that blueprints are used to give a broad overview of an intended feature and enough technical information for the PTL and other teams to ensure that work isn't being duplicated. Since we all work in teams, I think it is reasonable to expect every team to have a contact person that is responsible for ensuring that the team's blueprints are up-to-date with what they are actually working on. Internal to the team this can be managed however they see fit. It can be offloaded to individual developers or handled by a project manager, etc. If we can all strive to follow this limited use of blueprints, I think it gives us the advantages that they provide for project management without putting too much strain on the developers. Specs Detailed specs beyond a brief technical overview should not be required in all cases. It is strongly recommended (but not required) for a team to make available any internal specifications that they are using. For small features, a simple link to a public branch is enough. Detailed Specs should be required in the following cases: * A large feature that touches a lot of the code * Code that will need multiple merge proposals * Features that are being worked on by multiple teams * A feature that is blocking features by other teams. I think we could Branches Teams should be encouraged to keep their branches in the public as work goes on. This allows curious community members to drill down into the current development and see what is going on. This is especially important for teams using agile development. Merge Merges should be evaluated on merit. If we get a large feature without an associated blueprint/spec, we can help educate the developer on the blueprint / spec process, but i don't think we should block merging if the feature is well designed and tested. Obviously if the feature interferes with other blueprints in the pipeline, we can block it. In conclusion, I strongly agree with soren's comment that the core developers should be following the suggested process, and I will mea culpa in my own avoidance of blueprints. I think a lot of the issues the developers have had are due to a feeling that it is a) complicated and b) not valuable. Hopefully with the understanding of the value that has been provided in this thread and the clarification and suggestions I've provided, we can all improve our teamwork. Please let me know if I've missed anything. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal to defer existing OS API v1.1 to Diablo, for greater stability in Cactus
Thanks Justin, appreciate the input! Answers inline.
On Thursday, March 31, 2011 5:31pm, Justin Santa Barbara
jus...@fathomdb.com said:
I think there are a few distinct issues:
1) XML support. I was thinking that most XML issues would also be issues in
the JSON, so validating the XML will also serve as validating the JSON. I'd
appreciate an example here, but I agree in general that focusing on JSON is
acceptable - as long as its not just that we don't see the problems in JSON
because we're not validating it as thoroughly.
So the XML is generated based on the json, but it goes through an additional
transformation so just checking the XML does not ensure that the json is
correct.
Good point about an example, I should have provided one! Below is the output
for a JSON and XML request on the same resource (/servers/id). Things are
mostly correct until you get down to the IP address and metadata level.
{server:
{status: active,
hostId: 84fd63700cb981fed0d55e7a7eca3b25d111477b5b67e70efcf39b93,
addresses: {public: [], private: [172.19.1.2]},
name: metaserver,
flavorId: m1.tiny,
imageId: 1,
id: 6,
metadata: {data1: value1}
}
}
server flavorId=m1.tiny
hostId=84fd63700cb981fed0d55e7a7eca3b25d111477b5b67e70efcf39b93 id=6
imageId=1 name=metaserver status=active
addresses
public/
private
item
172.19.1.2
/item
/private
/addresses
metadata
data1
value1
/data1
/metadata
/server
Correct XML would be:
server flavorId=m1.tiny
hostId=84fd63700cb981fed0d55e7a7eca3b25d111477b5b67e70efcf39b93 id=6
imageId=1 name=metaserver status=active
addresses
public/
private
ip addr=10.176.42.16/
/private
/addresses
metadata
meta key=data1value1/meta
/metadata
/server
2) Missing features. I don't think of this as an API issue, unless these
are supported features which we simply aren't exposing. My understanding is
that it's the underlying support that's holding this back, not the API
itself.
As far as 1.1 goes, I think the backend features that we were waiting on are
there now, but as we all had a bunch of late merges, we didn't have the time to
implement the API side before feature freeze. For 1.0 missing features...we
honestly didn't look at those two (shared ips and backup scheduling) because we
didn't feel they added a ton of value above above what was coming in the 1.1
spec. So I'm not sure if the necessary backends are there, though I would guess
no. Someone else chime in here if that's wrong!
3) The v1.1 schema changes. To be honest, I'm still confused here. I think
you want to maximize compatibility with Cloud Servers v1.0, so it sounds
like you would also want a minimal v1.1 that was just the bare minimum
additional features to support additional features in nova (e.g.
changePassword action) I don't really understand where the 'nice to have'
(e.g. atom links) changes came from in that case. I think everyone would
support a minimal set of changes to the CloudServers v1.0 API; even if
people would rather have their own OpenStack API long-term, supporting the
two existing cloud APIs is an obvious win.
Given this, what makes the most sense to me is to focus on stability for
version 1.0 API excluding XML support. The bindings that are out there have
strong support for the JSON data formats in v1.0. As suggested, I think we
call the current mostly implemented 1.1 API experimental so as to give
access to any features that we need that are only in 1.1.
I think v1.0 is a good API, and has the advantage that a lot of existing
clients work with it. I would personally like XML support to be in there,
but I understand that we need to make sacrifices, so accept that the focus
should be on JSON in v1.0.
I think calling v1.1 experimental and discussing it at the Design Summit is
the right thing to do. If you need to extend v1.0 (e.g. to support
restartServer in v1.0), then I think you can make the call on
re-numberings.
One point I would like to ask about is how important is XML to the 1.0
implementation?
I personally would like to see XML support shipped, even if marked
experimental and not 100%. I had thought that getting the XML right would
mean we got the JSON right also, and it's easier to test the XML. However,
I totally agree that JSON should be our top priority. Given the time
situation, I think XML work should only be done to help the JSON (e.g.
adding namespaces to the XML lets us do a schema validation, which
indirectly helps us check the JSON = yes. Fixing XML output where the JSON
output is already valid = not a priority)
Justin
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help
Re: [Openstack] POC for Pluggable Network Service
Hi Hisaharu, Great to see some action happening on the topic of network service! Thanks for creating this detailed spec! We, at Midokura, would love to contribute to this project. I took a look at the code and noticed a few things: - You have started the merging of flat, flat_dhcp and vlan plugins into one, which we think is a good decision. We can continue on with creating a new plugin ourselves. - Database models and APIs seem to have gone through some makeover with a use of DAO classes, which we also think is great. One thing we want to contribute is to remove the authentication code from db/sqlalchemy module altogether and move it to db/api.py. Please let us know how we can start making commits to this project. If it's ok that we commit directly to this branch, we will send you our public keys. Thanks, Ryu 2011/4/1 Dan Wendlandt d...@nicira.com I second the comment about a great spec. I look forward to poking at this and working with you to incorporate feedback. After a quick pass, I think the work we have done with the network-service should play well within your model. Dan 2011/3/31 Jay Pipes jaypi...@gmail.com Just wanted to say thank you for putting together an excellent spec document. Thanks, jay 2011/3/31 石井 久治 ishii.hisah...@lab.ntt.co.jp: Hi Everyone, I have implemented a POC code for Pluggable Network Service at lp:~ntt-pf-lab/nova/network-service. And wrote the document of it http://wiki.openstack.org/NetworkServicePOC This document outlines the new network architecture for Nova that I would like to propose for the Diablo release. This is just a first draft, so I would love to get some feedbacks from the community to discuss and improve it. And hopefully attract some willing participants as well! Thanks, Hisaharu Ishii ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- ~~~ Dan Wendlandt Nicira Networks, Inc. www.nicira.com | www.openvswitch.org cell: 650-906-2650 ~~~ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Proposal to defer existing OS API v1.1 to Diablo, for greater stability in Cactus
I agree with Justin on 1. JSON may be acceptable, but I don't believe we are
validating throughly. For example, in the JSON below...active is not a valid
status, flavorId should be an integer, etc. That said, the JSON seems to be
pretty close. The XML is not that far behind it has the same problem as the
JSON plus a missing namespace and some bad elements. Personally, I think we may
be able to fix the XML with some creative WSGI and XSLT hacking but I'm not
sure how easy it would be incorporating that into the code.
We really need to be writing tests around this stuff. What we do in Rackspace
today is that we generate the example in the DevGuide in XML validate the XML
against the schema then translate to JSON, then compare the translated JSON
against the JSON example in the DevGuide. OR we take the JSON translate it to
XML and validate the XML against the schema AND compare the XML against the
example in the DevGuide...for instances where we expect input and output
(servers, images), we iterate through multiple iterations of this. Because
there's a schema in the loop, we can catch errors like the ones I mentioned
above even in the JSON. Little validation errors are easy to sneak in and they
do break clients. The only real protection that we have is good testing.
As for the missing features in 1.0, I don't think that they're a big deal. As
Justin stated, the underlying implementation is missing AND they've been
dropped from the 1.1 spec. We should wait till the implementation is done -- I
have a feeling they'll get implemented because I don't see Rackspace moving to
Nova without them :-) At that point, we can bring then in as extensions to
1.1, then put them into the core in a later version if we think they're worth
it.
As for changes in 1.1. I don't think we should be focused on maximizing
compatibility when we switch from one version to another. The whole purpose of
having different versions is that they introduce features that would otherwise
break clients. That is client developers will have to go back to the code and
make some changes in order to get things to work. If we always made compatible
changes there would be no reason for changing the version. I agree that we
should be able to support at least two active versions at one time to give
people a chance to migrate to the latest version. I also think we should be
investing in language bindings to help people along. Let's talk about the
changes that are coming in 1.1 and discuss exactly what we want those to look
like in the summit.
Finally, I'd also rather XML support be marked as experimental in 1.0 rather
than excluding it. We have a large number of clients would rather use XML,
because it's more testable or because they have better tooling.
-jOrGe W.
On Mar 31, 2011, at 7:24 PM, Gabe Westmaas wrote:
Thanks Justin, appreciate the input! Answers inline.
On Thursday, March 31, 2011 5:31pm, Justin Santa Barbara
jus...@fathomdb.com said:
I think there are a few distinct issues:
1) XML support. I was thinking that most XML issues would also be issues in
the JSON, so validating the XML will also serve as validating the JSON. I'd
appreciate an example here, but I agree in general that focusing on JSON is
acceptable - as long as its not just that we don't see the problems in JSON
because we're not validating it as thoroughly.
So the XML is generated based on the json, but it goes through an additional
transformation so just checking the XML does not ensure that the json is
correct.
Good point about an example, I should have provided one! Below is the output
for a JSON and XML request on the same resource (/servers/id). Things are
mostly correct until you get down to the IP address and metadata level.
{server:
{status: active,
hostId: 84fd63700cb981fed0d55e7a7eca3b25d111477b5b67e70efcf39b93,
addresses: {public: [], private: [172.19.1.2]},
name: metaserver,
flavorId: m1.tiny,
imageId: 1,
id: 6,
metadata: {data1: value1}
}
}
server flavorId=m1.tiny
hostId=84fd63700cb981fed0d55e7a7eca3b25d111477b5b67e70efcf39b93 id=6
imageId=1 name=metaserver status=active
addresses
public/
private
item
172.19.1.2
/item
/private
/addresses
metadata
data1
value1
/data1
/metadata
/server
Correct XML would be:
server flavorId=m1.tiny
hostId=84fd63700cb981fed0d55e7a7eca3b25d111477b5b67e70efcf39b93 id=6
imageId=1 name=metaserver status=active
addresses
public/
private
ip addr=10.176.42.16/
/private
/addresses
metadata
meta key=data1value1/meta
/metadata
/server
2) Missing features. I don't think of this as an API issue, unless these
are supported features which we simply aren't exposing. My understanding is
that it's the underlying support that's
