[Openstack] [GLANCE] Third draft of OpenStack Images API 2.0 proposal available for comment
Hello all, I've published the third draft of the new Images API proposal here: https://docs.google.com/document/d/19IapP5ziQp8ISuZIQh_CXVWx2um85T_PiT5hyNviRrE/edit Major changes from the 2nd draft include: * Addition of XML as well as JSON content type support * Addition of Zones resource * Use of JSON Schema and XSD for resource description documents * Addition of image classifications -- internal or external, depending on whether the master server containing image properties is controlled by the server publishing an image * Use of a type and format of the image, as per the mailing list discussion about container_format and disk_format * Removal of the OVF/OVA format type -- see note on migration of OVA files from 1.x servers to 2.0 servers in 3rd draft * Addition of example API call flows at the end of the draft document We welcome all feedback. Thanks, -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
[Openstack] Openstack Dashboard mismatch issue.
Hi openstack list, Currently, we are enabling dashboard in Openstack (diablo version) and meet a lot of mismatch issues. We used grid dynamic packed openstack within RHEL6 like this: $sudo rpm -i wget http://yum.griddynamics.net/yum/diablo-3/openstack/openstack-repo-2011.3-0.3.noarch.rpm The mismatch issues that we met: 1. Dashboard got the response data from keystone, but the data structure mismatched between dashboard and keystone: For example, In dashboard, role_id or user_id are actually the role's name and the user's name. Then it passes role_id OR user_id to keystone. However, keystone expects the role's id AND the user's id to perform the task. 2. Some method mismatches in openstackx and keystone. For example, openstackx uses POST but keystone accepts only PUT. 3. Others... So that, in order to enable the Dashboard, we need to debug the code for each item in Dashboard for Diablo openstack. My questions are: 1. What openstack version and Dashboard version are the dashboard developers working based on? 2. How future plan to solve this dependence issue between Dashboard and other project (nova, keystone and etc.) 3. If we has some fix in old version, what kind of thing we can do best to make it aviable for future release? Thank you! ___ 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] Openstack Dashboard mismatch issue.
See inline.. On Mon, Dec 12, 2011 at 4:27 PM, ygsnian ygsnian ygsn...@gmail.com wrote: My questions are: 1. What openstack version and Dashboard version are the dashboard developers working based on? There are two branches of every project. master and stable/diablo. All the master branches should generally work together, and all the stable/diablo should work together (and currently do). 2. How future plan to solve this dependence issue between Dashboard and other project (nova, keystone and etc.) I'm not sure there is an issue here? The diablo dashboard will work with diablo keystone/nova/etc while the essex dashboard will work with essex keystone/nova/etc... If they don't, that's a bug that should be fixed 3. If we has some fix in old version, what kind of thing we can do best to make it aviable for future release? That's what the stable/diablo branches are for! See http://wiki.openstack.org/StableBranch Also - It looks like the repo you are using provides diablo-3 packages, diablo-4 was the final Diablo release.. ___ 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] trusted computing and nova
Behalf Of Mark Washenberger Do we need anything more than a way to inject a third-party filter into schedulers? I'm assuming that we need to schedule based on whether or not the attestation server verifies the host. And I understand that this situation introduces some peculiar and novel requirements on the scheduler. But I don't think it makes sense to deduce from that that we should write an attestation client into nova and create a new scheduler and manager service. Instead, we should robustify (is that even a word? :-) the plug-ability of the scheduler with these requirements in mind. Nova currently assuming all the capabilities are directly provided updated fully through RabbitQ by components as Compute, Network and Volume, which won't be sufficient. Injecting new attribute into any of the 3 cap. Outside the above 3 components isn't persistent. For example, trust_state, of trusted computing, which to be created through channel other than RabbitQ needs to be inserted into A 4th cap, which supports individual attribute update; otherwise it is to be trashed by compute nodes if it got lump into Compute cap. Any thought of providing such 4th cap.? Filter provides sufficient Select nodes with attribute(s) of which enforce the positive qualifier; it depends users to specify NOT qualifier to not getting instances to run on non-qualified nodes. Any way to enforce negative qualifier is no positive qualifier specified? Thanks, -Fred ___ 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] Providing packages for stable releases of OpenStack
+1 for OpenStack Essex LTS + Ubuntu 12.04 LTS On Thu, Dec 8, 2011 at 1:57 PM, Ghe Rivero g...@debian.org wrote: I'm ok with everything so far, but from http://wiki.openstack.org/StableBranch: *The stable branch will only be maintained until the next release is out. This period may be extended if there are volunteers to maintain it beyond this point.* With a 6 months release cycles, it still looks a sort period of time for a production deployment, and some people/companies can not relay on those volunteers to appear to maintain it for more time. Is there any plan (or can be proposed) to have some kind of LTS release? I've read some place that essex + Ubuntu 12.04 LTS can be a good candidate; essex is considered the first production ready release, but it will not have quantum, we are tying openstack within an specific distribution... Anyway, (ubuntu12.04 + essex)^LTS looks great, and we have time to discuss what to do for a future LTS release. Ghe Rivero On Thu, Dec 8, 2011 at 5:59 PM, Duncan McGreggor dun...@dreamhost.com wrote: On 07 Dec 2011 - 08:15, Mark McLoughlin wrote: On Tue, 2011-12-06 at 14:12 -0800, Duncan McGreggor wrote: On 06 Dec 2011 - 13:52, Duncan McGreggor wrote: On 06 Dec 2011 - 21:14, Thierry Carrez wrote: Tim Bell wrote: I'm not clear on who will be maintaining the stable/diablo branch. The people such as EPEL for RedHat systems need to have something with the appropriate bug fixes back ported. There are an increasing number of sites looking to deploy in production and cannot follow the latest development version. Agreed on the need, we discussed this at length during the design summit. The stable branches have been established and are maintained by the OpenStack Stable Branch Maintainers team. Currently this team is mostly made of distribution members (Ubuntu and Fedora/RedHat, mostly) collaborating on a single branch to avoid duplication of effort. See: https://launchpad.net/~openstack-stable-maint http://wiki.openstack.org/StableBranch Okay, I think this mostly addresses item #4 that I wanted to add to your summary, Thierry. I do have the following minor concerns, though: * that wiki page's summary (intro sentence) only specifically mentions Diablo; I'd like to see something along the lines of currently focusing on Diablo. If these processes evolve into a successful model, they will be applied to all future releases. Added. * the discussion on the page treats this as an experiment (this is good!), but I'd like to see a phrase alone the lines of if this experiment is successful, we will do X to ensure these processes become an official part of the workflow. Cleaned up the this is an experiment text a bit, it's gone beyond an experiment now I think. Very cool, Mark! Thanks so much!! d ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- .''`. Pienso, Luego Incordio : :' : `. `' `-www.debian.org GPG Key: 26F020F7 GPG fingerprint: 4986 39DA D152 050B 4699 9A71 66DB 5A36 26F0 20F7 ___ 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] trusted computing and nova
Behalf Of Mark Washenberger Do we need anything more than a way to inject a third-party filter into schedulers? I'm assuming that we need to schedule based on whether or not the attestation server verifies the host. And I understand that this situation introduces some peculiar and novel requirements on the scheduler. But I don't think it makes sense to deduce from that that we should write an attestation client into nova and create a new scheduler and manager service. Instead, we should robustify (is that even a word? :-) the plug-ability of the scheduler with these requirements in mind. Mark, There may be some mis-understanding here, The trusted computing patch has already taken the plug-in approach in Nova. That is 1. A new filter driver, inherited from json_filter, to filter Trust_state specific information. This is using existing filter FLAGS.default_host_filter to configuted in 2. A manager_integrity, invoked as part of SchedulerManager, to pull trust_state data periodically - this is configured in through FLAGS.scheduler_manager One thing to improve is how to get a common HTTPS client service to be supported in Nova, is there any other component may use external http connection? Other support needed from existing Nova is to support extra capability that differ from existing Compute/Network/Volume capabilities (Described in the other thread) Hope this clarify the plug-in discussion -Fred ___ 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] unit and integration tests results for Gerrit
Hello all, We just turned on a [https://github.com/dprince/bellows] Bellows feature that will automatically update Gerrit reviews with SmokeStack test results. Each Gerrit review should have a comment that looks something like this: SmokeStack Results (patch set 2): Unit Success: http://smokestack.openstack.org/?go=/jobs/5570 Libvirt Success: http://smokestack.openstack.org/?go=/jobs/5568 XenServer Success: http://smokestack.openstack.org/?go=/jobs/5569 --- The results we obtain are generally good but aren't perfect. I have a high level of confidence in the unit test results. Failures in Libvirt and XenServer require a bit more investigation but are generally useful as well. Hopefully this information is helpful! I'm not in a position to focus on this full time however I'll do the best I can to keep things running smoothly. Pull requests accepted. Dan ___ 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] Openstack and JClouds
hi all anyone experience with OpenStack with JClouds i want to know, how JClouds work in Nova Controller. still dont get it.. -- Frans Thamura (曽志胜) Shadow Master and Lead Investor Meruvian. Integrated Hypermedia Java Solution Provider. Mobile: +628557888699 Blog: http://blogs.mervpolis.com/roller/flatburger (id) FB: http://www.facebook.com/meruvian TW: http://www.twitter.com/meruvian / @meruvian Website: http://www.meruvian.org We grow because we share the same belief. ___ 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] Inspired Meetings!
Hi Stackers! Last week I sat in on a few of the OpenStack IRC meetings: CI, General meeting, and QA . The meetings left me pumped for this week! If like me, meetings generally turn you off, these are meetings of a different stripe. I'm inspired by the momentum, and wishing I had time to dive into other areas as well, and -- gasp! -- attend more meetings! Each meeting also includes open questions at the end. If you are only going to attend one meeting this week it will have to be tomorrow's General Meeting, Tuesdays at 2100 UTC. It might be better named the OpenStack Project Release Status meeting. ttx (Thierry) does a first class job chairing the meeting. ttx is a maestro coaxing and interpreting information from long lists of blue prints, bug reports, and most importantly thanks to the excellent communications of those in attendance. It's incredible that in an hour, thanks to ttx and the component leads sharing, I got a sense of where each of the major components are -- essex-2 e2 has been very productive, it's not done yet! and we're lining ourselves up for a monster of an e3 (as it should be) ;-) Add https://www.google.com/calendar/ical/bj05mroquq28jhud58esggq...@group.calendar.google.com/public/basic.ics to your calendar program and be sure to make it the meetings tomorrow that interest you. See you on #openstack-meeting on chat.freenode.net , http://wiki.openstack.org/Meetings Cheers, Lloyd ___ 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] [subteams] Update from nova-subteams Meeting
Hello everyone, TL, DR: * subteam discussions will happen on the main mailing list * inter-team communication will use the [subteams] header * subteam lead is responsible for making sure ML discussion doesn't devolve into bikeshedding * launchpad groups will remain for blueprint tracking * subteam leads need to pay more attention to blueprint targetting Longer Version: We had a quick subteam meeting to discuss the best way to communicate between subteams. I've included the minutes at the bottom of this email for anyone who missed it. We are going to try and improve our communication without adding move meetings. Subteams are also encouraged to do as much as possible through the ML so that people in all timezones can collaborate. We recognize that meetings may be needed occasionally, but we can schedule these as needed. So people can filter properly, when discussing team related topics, please use the short [header] listed on the page here: http://wiki.openstack.org/Teams#Nova_subteams Subteam leads, you're responsible for shepherding discussions with your header. Keep the discussion pointed so that we don't devolve into bikeshedding. Meta-communication with subteams will use the [subteams] header. I will bugging team leads about blueprints using this header, so team leads, pay attention to it! Subteam leads, check your blueprints and target them. I will be doing a review of untargetted blueprints and sending out an email with specific concerns and requests. Thanks, Vish Meeting Minutes: == #openstack-meeting Meeting == Meeting started by vishy at 21:04:23 UTC. The full logs are available at http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-12-12-21.04.log.html . Meeting summary --- * First Nova Subteam Meeting (vishy, 21:04:37) * Best method of communication (vishy, 21:05:25) * Goals for communication: (vishy, 21:05:41) * Efficiently managing and targeting blueprints (vishy, 21:06:08) * Addressing shared blueprints and work across teams (vishy, 21:06:26) * Ensuring we aren't duplicating work (vishy, 21:06:34) * Ensuring we aren't blocking each other (vishy, 21:06:42) * Staying abreast of decisions made by teams (vishy, 21:06:49) * Staying aligned with the release schedule (vishy, 21:06:58) * IDEA: the team leads are probably enough to prevent bikeshedding (vishy, 21:10:48) * IDEA: so we can return to ML discussions if the team leads are willing to keep the discussions focused and directed. (vishy, 21:11:15) * ACTION: vishy to email the list explaining use of the list by subteams. (vishy, 21:14:09) * subteams will not use separate mailing lists, but still have value for blueprint tracking (vishy, 21:17:30) * Blueprint management and targetting (vishy, 21:17:53) * we need to get better at assigning and targetting blueprints (vishy, 21:18:16) * ACTION: bcwaldon to clean up nova-api blueprints and email about targeting (vishy, 21:25:57) * ACTION: vishy to look over other blueprints and send out specific email to [subteam] highlighting issu es (vishy, 21:26:26) * open discussion (vishy, 21:28:12) Meeting ended at 21:29:18 UTC. Action items, by person --- * bcwaldon * bcwaldon to clean up nova-api blueprints and email about targeting * vishy * vishy to email the list explaining use of the list by subteams. * vishy to look over other blueprints and send out specific email to [subteam] highlighting issu es People present (lines said) --- * vishy (75) * bcwaldon (49) * _0x44 (6) * mtaylor (3) * openstack (2) Generated by `MeetBot`_ 0.1.4 ___ 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] e2 blueprints
Hey Everyone, There are a couple of blueprints marked essential that haven't quite made it in. The review/update process was lagging a bit, so I went ahead and made the requested changes on them. We really need these to get in for e-2, so please take a minute to check them out and make sure i haven't broken anything badly. They were both very close before my changes, so hopefully they are good. The reviews are here: https://review.openstack.org/#change,1695 https://review.openstack.org/#change,1202 Thanks, 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
[Openstack-volume] [Blueprint nova-volume-snapshot-backup-api] Nova Volume Snapshot / Backup API
Blueprint changed by OpenStack Hudson: Whiteboard changed: I have implemented the os api extension to query/create/delete snapshots. You can refer to the change request: https://review.openstack.org/#change,1202 Change-Id: Id3e1ad39ef791b93dd014cada87c2d295454701f Addressed by: https://review.openstack.org/1202 Added support for creating nova volume snapshots using OS API. + + + Gerrit topic: https://review.openstack.org/#q,topic:bug/883676,n,z -- Nova Volume Snapshot / Backup API https://blueprints.launchpad.net/nova/+spec/nova-volume-snapshot-backup-api -- Mailing list: https://launchpad.net/~openstack-volume Post to : openstack-volume@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-volume More help : https://help.launchpad.net/ListHelp
