Re: [Openstack] [docs] Japanese version of Operations Guide is now available
お疲れさまです！ This is great work! The doc must be useful for Japanese operators :) Best Nachi 2013/7/25 Jake G. : > お疲れ様でした！ > > 英語版より絶対分かりやすいと思う。母国語が英語なのにわきわからない。笑 > > よろしくお願いします。 > > On 2013/07/26, at 1:17, Akihiro MOTOKI wrote: > > Hi all, > > We, Japanese OpenStack Users Group, are happy to announce > Japanese version of OpenStack Operations Guide is published. > The document is available at > http://openstack-ja.github.io/openstack-manuals/openstack-ops/content/ > > We announced it at OpenStack 3rd anniversary event in Japan yesterday. > We really thank doc team support and the authors of Operations Guide. > > While the document is available on GitHub pages currently, we have a plan > to publish it on docs.openstack.org and working with I18N and docs team. > > Translation efforts of other OpenStack documents including Operations Guide > are going in several languages. It also proves OpenStack community is > getting larger. > > Thanks > Akihiro Motoki > > ___ > 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 > ___ 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] Folsom TryStack on RHEL
Hi Syed Your welcome! :) And, Sorry for double post Best Nachi 2013/4/24 Syed Armani : > > Thank you very much Nachi for sharing this good news. Its good to know > that Red Hat is helping out in keeping trystack.org healthy and running. > > Best regards, > Syed > > On Wednesday 24 April 2013 04:46 AM, Nachi Ueno wrote: >> Hi TryStack Users >> >> Please take my apologies for delaying deploy x86 Zones. >> We are happy to announce new Folsom X86 zone. >> >> http://trystack.org/ >> http://x86.trystack.org/dashboard/ >> >> One great news is Red Hat's starts contributing, >> The cluster is now managed by Redhat and it is running on RHEL. >> Some people may think "Oh it's Folsom version?". >> No worries, Redhat has already started the planning to >> upgrade it to Grizzly! >> >> The cluster has only 20 machines, so please use it kindly :) >> There are already 4713 members of the TryStack Facebook group, and >> 3627 requests to join. >> So if all of users start boot vm at same time, the cluster may get upset. >> We will check the status of the cluster, gradually adding new users >> for the clusters. >> >> Best. >> Trystack admin team >> >> ___ >> 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] Folsom TryStack on RHEL
Hi TryStack Users Please take my apologies for delaying deploy x86 Zones. We are happy to announce new Folsom X86 zone. http://trystack.org/ http://x86.trystack.org/dashboard/ One great news is Red Hat's starts contributing, The cluster is now managed by Redhat and it is running on RHEL. Some people may think "Oh it's Folsom version?". No worries, Redhat has already started the planning to upgrade it to Grizzly! The cluster has only 20 machines, so please use it kindly :) There are already 4713 members of the TryStack Facebook group, and 3627 requests to join. So if all of users start boot vm at same time, the cluster may get upset. We will check the status of the cluster, gradually adding new users for the clusters. Best. Trystack admin team ___ 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] Use of MAC addresses in Openstack VMs
Hi Brad > To me, a global range that everyone is using that's provided by OpenStack is > seems much worse than just calculating an arbitrary private range by flipping > bit b2 to 1 as shown in the wiki article below. As long as you set this, > you're guaranteed not to collide with any registered mac OUIs from other > vendors (assuming you generate a fairly random range with the remaining bits) > and offer a reasonable guarantee of uniqueness if you end up integrating at > L2 with other clouds. If, however, many OpenStack clouds end up using the > same OUI because the foundation globally registers one, your risk of > collision during L2VPN between OpenStack clouds would be higher. > > http://en.wikipedia.org/wiki/MAC_address IMO, this is not matter of OUI by Openstack foundation. Because users who has not use there own OUI may use default configuration value of OUI bit which is not owned by us. May be it could be another vendor's OUI. My proposal is the default OUI value should be owned by OpenStack foundation if $2000 isn't concern for OpenStack foundation. Thanks Nachi > Just my two cents.. personally even if the foundation had a range I'd feel > safer on a private scope than one that I KNOW a bunch of other clouds are > using. > > Thanks! > > Brad McConnell > Rackspace network guy > > > From: openstack-bounces+bmcconne=rackspace@lists.launchpad.net > [openstack-bounces+bmcconne=rackspace@lists.launchpad.net] on behalf of > Eric Windisch [e...@cloudscaling.com] > Sent: Saturday, October 20, 2012 2:54 PM > To: Salvatore Orlando > Cc: Vinay Bannai; openstack@lists.launchpad.net > Subject: Re: [Openstack] Use of MAC addresses in Openstack VMs > > Sent from my iPad > > On Oct 20, 2012, at 10:19, Salvatore Orlando wrote: > >> I understand your concerns about conflicts with already assigned OUIs. >> It is however my opinion that it is not up to the Openstack Foundation, but >> to entities deploying Openstack, to buy MAC OUIs. > > For comparison and reference, Xen has its own OUI which is used by default > for its VMs. Users of Xen do not need to apply for their own OUIs and I > don't believe they should. > > It isn't necessary for VMs to have globally unique MACs, but they shouldn't > overlap with devices from other vendors. > > I believe OpenStack should have its own OUI. > > Regards, > Eric Windisch > ___ > 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 ___ 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] TC Candidacy
+1 ! Thank you for your working hard for CI :) 2012/9/19 Monty Taylor : > Hi everybody! > > I'd like to run for a seat on the Technical Committee. > > - OpenStack Experience - > > I run the CI and Developer Automation team for OpenStack. There hasn't > always been a team, but as long as there has been, I've been doing it. > Before there was a proper team, there was Soren and I, and before that > there was just me. I set up the original Tarmac-based trunk gate that we > used before Gerrit, and I'm the original owner on many of the Launchpad > resources (because it turns out some human must be the ultimate owner of > things there) So it's pretty easy to say without boasting that there is > very little about the tooling that runs the project that I don't know > about, both in its current form and the history that got us to its > current form. > > My commits and reviews can be seen here: > https://review.openstack.org/#/q/reviewer:mordred%2540inaugust.com+OR+owner:mordred%2540inaugust.com,n,z > > - Other Experience - > > I work at HP where I lead a team of people who staff the rest of the CI > team. I do what I can as part of my job there to ensure that the > OpenStack Dev systems always have the resources they need to operate > effectively. Before HP I worked at Rackspace doing the same thing. > > Before OpenStack at Rackspace I was a core developer on Drizzle, having > moved with the rest of the Drizzle team to Rackspace when Sun got bought > by Oracle. I was lucky enough to get involved in Drizzle hacking from > the beginning of that project while I was a Senior Consultant for MySQL > Inc (and then for Sun when we got bought) Although it doesn't come up in > this context very often, I'm pretty stinking good at MySQL Scaling and > High Availability. I've been a Python hacker since I wrote the SNPP > protocol library for Python in 2000, and have experience as both a > developer and a *nix sysadmin stretching back to 1994. > > Recently I became a member of the Python Software Foundation, and I sit > on the OpenStack Foundation Board. > > - Why I should be on the Technical Committee - > > The TC provides direction to the project as a whole and acts as a > collaboration point and focus for consensus between the projects. Often > times things that are decided by the TC have a direct effect on the > automation systems that we use to run things ... so having someone from > the CI and Automation teams represented seems like a really good idea. > Additionally, since I tend to be cross-project focused rather than > involved in any one specific project, I'd like to think that I have a > decent unbiased perspective on issues that are related to project > agreement and consistency. > > Thanks for your consideration! > Monty > > ___ > 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] TC candidacy
+1 ! 2012/9/14 Tres Henry : > Hella +1 > > On Sep 14, 2012, at 10:55 AM, "Bhandaru, Malini K" > wrote: > >> +1 >> >> -Original Message- >> From: openstack-bounces+malini.k.bhandaru=intel@lists.launchpad.net >> [mailto:openstack-bounces+malini.k.bhandaru=intel@lists.launchpad.net] >> On Behalf Of Anne Gentle >> Sent: Friday, September 14, 2012 10:25 AM >> To: openstack@lists.launchpad.net >> Subject: [Openstack] TC candidacy >> >> I'd like to propose myself as a Technical Committee candidate for one of the >> open seats in the current election. >> >> ==Background and Experience== >> Hi, I'm Anne Gentle, I work at Rackspace serving as the OpenStack doc >> coordinator. I put "Content Stacker" on my business cards to point out the >> power of content coming from many people and many projects that I happily >> stack into organized sites. I maintain the docs.openstack.org and >> api.openstack.org site by running the documentation project like a code >> project, with blueprints, bugs, and task tracking. Also documentation is >> published continuously and automatically with reviews in the Gerrit system >> like code. I've been working on OpenStack for two years. Here's a link to my >> contributed patches and reviews on Gerrit. >> https://review.openstack.org/#/q/reviewer:anne%2540openstack.org,n,z >> >> My open source experience precedes my OpenStack history. Starting around >> 2008, I worked with FLOSS Manuals writing open source manuals for open >> source software, http://flossmanuals.net. I'm always researching the latest >> tools, techniques, and limited amount of academic research available about >> open source and documentation. This year I released a 2nd edition of my >> book, Conversation and Community: >> The Social Web for Documentation that includes a chapter about open source >> and documentation. It's a unique field and I'm quite drawn to it. >> >> ==Technical Expertise== >> I've been working on technical documentation in software and IT and have >> built a unique perspective through the years on how to integrate >> documentation closely with fast-moving code. I also have the technical >> knowledge and user perspective for consuming OpenStack APIs. I'm a fast >> learner and open to many tools and processes related to code and docs. >> >> OpenStack affords us all opportunities to design, implement, experiment, and >> build upon documentation and I enjoy working with the community to >> continually improve the documentation. Thanks for your consideration. >> >> Anne Gentle >> --- >> http://justwriteclick.com >> http://www.linkedin.com/in/annegentle >> >> ___ >> 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 > > > ___ > 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] TRYSTACK DOWN TIME AND RUNTIME ERRORS!!!
Hi Syed Sorry for inconvenience. Recent several website down is due to misconfiguration of Apache. Some proxy settings looks wrong, so IMO this is not problem of OpenStack itself. I'll fix this issue ASAP. Thank you for your notice Nachi Ueno 2012/9/14 Syed Armani : > > Hi, > > Most of the people who come to try OpenStack via trystack.org have started > complaining that trystack is down most of the times. The first impression > they draw from this is that "MAY BE OPENSTACK IS UNRELIABLE". This is > creating a false impression on the people who want to try openstack. > https://www.facebook.com/groups/269238013145112/ > > Cheers! > Syed Armani ___ 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] trystack.org down?
Hi Glen Thank you for your report and sorry for inconvenience. It is up now. Thanks Nachi Ueno 2012/9/4 Glen Campbell : > Sorry if this has been asked before, but has the trystack.org service been > suspended? I haven't been able to reach it for a week or more. > > -- > Glen Campbell • Developer Advocate, Rackspace Developer Relations Group > glen.campb...@rackspace.com • http://glenc.co • @glenc > > > > > ___ > 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] [Netstack] [openstack-dev] [Quantum] Multi-host implementation
Hi Dan Thank you for pointing this. Yusuke updated design spec. https://blueprints.launchpad.net/quantum/+spec/quantum-multihost-dhcp 2012/8/6 Dan Wendlandt : > Hi Nachi, > > I've reviewed the code and added comments. I'd like to see at least a basic > spec describing the proposed approach (need only be a couple paragraphs, > perhaps with a diagram) linked to the blueprint so we can have a design > discussion around it. Thanks, > > Dan > > > On Fri, Aug 3, 2012 at 1:03 PM, Nachi Ueno wrote: >> >> Hi folks >> >> Sorry. >> I added openstack-...@lists.openstack.org in this discussion. >> >> 2012/8/3 Nati Ueno : >> > Hi folks >> > >> >> Gary >> > Thank you for your comment. I wanna discuss your point on the mailing >> > list. >> > >> > Yusuke pushed Multi-host implementation for review. >> > https://review.openstack.org/#/c/10766/2 >> > This patch changes only quantum-dhcp-agent side. >> > >> > Gary's point is we should have host attribute on the port for >> > scheduling. >> > I agree with Gary. >> > >> > In the nova, vm has available_zone for scheduling. >> > So Instead of using host properties. >> > How about use available_zone for port? >> > >> > Format of availability_zone is something like this >> > available_zone="zone_name:host". >> > >> > We can also add availability_zone attribute for the network as a >> > default value of port. >> > We can write this until next Monday. >> > However I'm not sure quantum community will accept this or not, so I'm >> > asking here. >> > >> > If there are no objections, we will push zone version for review. >> > Thanks >> > Nachi >> > >> > ___ >> > 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-dev mailing list >> openstack-...@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > ~~~ > Dan Wendlandt > Nicira, Inc: www.nicira.com > twitter: danwendlandt > ~~~ > > > -- > Mailing list: https://launchpad.net/~netstack > Post to : netst...@lists.launchpad.net > Unsubscribe : https://launchpad.net/~netstack > 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] [Quantum] Update policy of device_id
Hi folks Sorry. I added openstack-...@lists.openstack.org in this discussion. 2012/8/3 Nati Ueno : > Hi folks > > I report this bug recently. > > device_id should not be updated twice > https://bugs.launchpad.net/quantum/+bug/1031473 > > Now, a user can update device_id which may cause problem. > > This is related to port id spec for nova boot. > https://bugs.launchpad.net/nova/+bug/1031096 > > My question is how we should deal with port on the failure or deletion. > > My patch will delete the port on failure or deletion > https://review.openstack.org/#/c/10639/ > > Another spec could be update port device_id for None. > But this is depends on how we solve bug 1031473. > > Any thought? > > -- > Nachi Ueno > email:nati.u...@gmail.com > twitter:http://twitter.com/nati > > ___ > 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] [Quantum] Multi-host implementation
Hi folks Sorry. I added openstack-...@lists.openstack.org in this discussion. 2012/8/3 Nati Ueno : > Hi folks > >> Gary > Thank you for your comment. I wanna discuss your point on the mailing list. > > Yusuke pushed Multi-host implementation for review. > https://review.openstack.org/#/c/10766/2 > This patch changes only quantum-dhcp-agent side. > > Gary's point is we should have host attribute on the port for scheduling. > I agree with Gary. > > In the nova, vm has available_zone for scheduling. > So Instead of using host properties. > How about use available_zone for port? > > Format of availability_zone is something like this > available_zone="zone_name:host". > > We can also add availability_zone attribute for the network as a > default value of port. > We can write this until next Monday. > However I'm not sure quantum community will accept this or not, so I'm > asking here. > > If there are no objections, we will push zone version for review. > Thanks > Nachi > > ___ > 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] [KeyStone] Requestid, context, notification in Keystone
Hi Joe,Jay > Thanks Jay > Joe This is from quantum - Quantum Quantum Notification https://blueprints.launchpad.net/quantum/+spec/quantum-notifications Improve scalability by eliminating agent DB polling https://blueprints.launchpad.net/quantum/+spec/scalable-agent-comms ( This blueprint trying to introduce context parameter in quantum ) IMO, it is great if we can provide a common way to handle request across projects. We can work for Keystone for F3 :) Nachi 2012/7/23 Joseph Heck : > Thanks Jay! > > On Jul 23, 2012, at 9:49 AM, Jay Pipes wrote: > >> On 07/21/2012 02:57 AM, Joseph Heck wrote: >>> Hey Nachi >>> >>> If by this you mean the idea that a request ID is created at a user request >>> action, and then propagated through all relevant systems and API calls to >>> make tracing the distributed calls easier, I'm totally in favor of the >>> idea. Distributed tracing through the calls has been a real pain in the a... >>> >>> I'm afraid I haven't been watching the other projects closely enough to >>> realize that this was getting implemented - any chance you could point out >>> the relevant change reviews so I could see where/how the other projects >>> have been doing this? >> >> Hey Joe, >> >> Here is a relevant patch for Glance: >> >> https://review.openstack.org/#/c/9545/ >> >> Best, >> -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 > > > ___ > 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] [KeyStone] Requestid, context, notification in Keystone
Hi Joe Nova ,Glance,Quantum(WIP) support Requestid, context, notification concept. IMO, Keystone should also have same functionality. Do you have any thought about this? Thank you in advance Nachi Ueno ___ 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] Keystone Federation
Sorry for my wrong mail 2012/7/5 Nachi Ueno : > Let's use skype > > Mine is nati.ueno > > 2012/7/5 Matt Joyce : >> Don't know if we want it. >> >> But we may want to consider the idea of satellite read only keystone >> servers. >> >> Mind you that may just be solving problems we don't even have yet. >> >> -Matt >> >> >> On Thu, Jul 5, 2012 at 11:26 AM, Adam Young wrote: >>> >>> I am contemplating writing up a post-Folsom Blueprint for Keystone >>> Federation and /or replication, and would like to solicit input from the >>> community. >>> >>> With Signed tokens, we can provide the name of the Keystone server that >>> signed the token. With this comes the need to verify that the specified >>> Keystone server is a valid server. The logical way would be to check it >>> against the service catalog. I think the flow should go something like >>> this: >>> >>> when you start up a service like glance it should have a Keystone server >>> specified. >>> >>> When a token comes in with Keystone server that it does not recognize, it >>> queries the known Keystone server's service catalog to see if the keystone >>> server is a registered endpoint. This service catalog can get cached for >>> some short amount of time to ensure we don't trigger a flurry of activity on >>> a series of bogus requests. >>> >>> When a new Keystone server comes on line, it gets registered with an >>> existing Keystone server. At this point, it requests its token signing >>> certificate. Once it recieves the signing cert, an AMQP message then goes >>> out to the other Keystone servers announcing the new keystone service. >>> >>> Retirement of a Keystone server would be done in a similar way. >>> >>> There are three scenarios I could see: >>> >>> 1) No one Keystone server would hold a complete user or tenant list. >>> Instead, each would hold a subset of the tenants. A user might exist in >>> multiple Keystone databases if they are enrolled in multiple tenants, some >>> of which are in one Keystone, some of which are in another. >>> >>> 2) The entire user database is synchronized across all of the keystone >>> instances. >>> >>> 3) The Keystone instances use a single shared DBMS and are automatically >>> synchronized. Federation is just for redundancy and scaling. >>> >>> I don't want to build this just to build it. I'd like to know if A) >>> there is a real need for Keystone Federation and B) If anyone else has >>> thought through the problem and encountered issues I have not enumerated. >>> If there is enough interest, I will edit the discussion into a blueprint. >>> >>> >>> >>> ___ >>> 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 >> ___ 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] Keystone Federation
Let's use skype Mine is nati.ueno 2012/7/5 Matt Joyce : > Don't know if we want it. > > But we may want to consider the idea of satellite read only keystone > servers. > > Mind you that may just be solving problems we don't even have yet. > > -Matt > > > On Thu, Jul 5, 2012 at 11:26 AM, Adam Young wrote: >> >> I am contemplating writing up a post-Folsom Blueprint for Keystone >> Federation and /or replication, and would like to solicit input from the >> community. >> >> With Signed tokens, we can provide the name of the Keystone server that >> signed the token. With this comes the need to verify that the specified >> Keystone server is a valid server. The logical way would be to check it >> against the service catalog. I think the flow should go something like >> this: >> >> when you start up a service like glance it should have a Keystone server >> specified. >> >> When a token comes in with Keystone server that it does not recognize, it >> queries the known Keystone server's service catalog to see if the keystone >> server is a registered endpoint. This service catalog can get cached for >> some short amount of time to ensure we don't trigger a flurry of activity on >> a series of bogus requests. >> >> When a new Keystone server comes on line, it gets registered with an >> existing Keystone server. At this point, it requests its token signing >> certificate. Once it recieves the signing cert, an AMQP message then goes >> out to the other Keystone servers announcing the new keystone service. >> >> Retirement of a Keystone server would be done in a similar way. >> >> There are three scenarios I could see: >> >> 1) No one Keystone server would hold a complete user or tenant list. >> Instead, each would hold a subset of the tenants. A user might exist in >> multiple Keystone databases if they are enrolled in multiple tenants, some >> of which are in one Keystone, some of which are in another. >> >> 2) The entire user database is synchronized across all of the keystone >> instances. >> >> 3) The Keystone instances use a single shared DBMS and are automatically >> synchronized. Federation is just for redundancy and scaling. >> >> I don't want to build this just to build it. I'd like to know if A) >> there is a real need for Keystone Federation and B) If anyone else has >> thought through the problem and encountered issues I have not enumerated. >> If there is enough interest, I will edit the discussion into a blueprint. >> >> >> >> ___ >> 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 > ___ 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] request and transaction IDs across all projects
>> Thoughts? Do you buy the need for both a request ID and a transaction ID? > > > Sure. Just curious where you think the dividing line is -- the project > (Nova, Glance) or the service/workers (nova-api, nova-compute, etc). IMO, we should use one single id to track transaction for all project. Instead, we should manage relationship between per project request id and inter project transaction id. > Best, > -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 ___ 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] request and transaction IDs across all projects
+1 In addition, Nova itself should accept request ID as a transaction ID. Nova is also one of callee in the sequence of transaction. Nachi 2012/6/11 Gabe Westmaas : > In nova we use a request ID to to help in finding all logs associated with > a particular request, and this has proven to be extremely useful when > debugging issues. This should be taken a bit further, in two different > directions. > > First, I'd like to see the request ID stored along with the any faults > that are registered, and I'd like to see that request ID returned in the > fault data. Returning it in the fault data can start as an extension for > now, and that should be able to move forward into the API pretty easily. > > Second, I'd like to figure out how we can extend this concept to all the > openstack services. I see two competing desires here. First, we want to > know about a particular request to a given service and second we want to > know about an overall transaction across all services. So, for example, a > single create server request may cause multiple requests to glance, and > depending on the issue, it would be great to both tie those together or > investigate separately. To this end, I'd like to see both a request ID > and a transaction ID. I'd like to see both these items in log, and I'd > like all OpenStack services to obey the rule that if the transaction ID is > set, don't reset it to anything else, but always add a request ID. > > Thoughts? Do you buy the need for both a request ID and a transaction ID? > I think the biggest change would be for swift, which already has a tx- > header that gets set randomly no matter what (if that middleware is > enabled). I can make blueprints for both the points above if yes. > > I'd love to get request IDs into glance, melange and quantum (maybe > already there?) in particular as quickly as possible. > > Gabe > > > ___ > 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] Development/Debugging
FYI RPDB (Remote pdb) is also helpful :) http://pypi.python.org/pypi/rpdb/ Nachi 2012/6/11 hitesh wadekar : > Awesome explaination Mandar. > > Thanks, > Hitesh > > > On Tue, Jun 12, 2012 at 10:12 AM, Vaze, Mandar > wrote: >> >> > ... so it makes sense to go through each daemon at a time using pdb. >> >> Not sure what you mean, but you can easily put set_trace() in multiple >> daemons at the simultaneously, in fact it is useful to trace the flow across >> various openstack services. >> >> -Mandar >> >> >> __ >> Disclaimer:This email and any attachments are sent in strictest confidence >> for the sole use of the addressee and may contain legally privileged, >> confidential, and proprietary data. If you are not the intended recipient, >> please advise the sender by replying promptly to this email and then delete >> and destroy this email and any attachments without any further use, copying >> or forwarding >> >> ___ >> 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 > ___ 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] How to setup vncproxy with ubuntu precise package?
Thanks! Yong! 2012/4/12 Yong Sheng Gong > Hi, please see if following text can help. > > To enable vnc console access VMs started by OpenStack, we need many > components to collaborate. > >- Components on control node > - nova-api, which is API server of OpenStack > - nova-consoleauth, which is used to authorize vnc client > - noVNC, which is a VNC proxy for browser. An alternative proxy is > nova-xvpvncproxy, which can accessed by a Java client at > https://github.com/cloudbuilders/nova-xvpvncviewer. >- Components on compute node > - nova-compute, which is nova binary to instantiate VMs > - libvirt driver, which is used by nova-compute to interact with > libvirt server > - VNC server, which is part of hypervisor? > > Steps for user to access VNC console > > > 1. user gets the vnc console by command： > [root@robinlinux utils]# nova get-vnc-console myserver20 novnc > > > nova-api accepts this request, and then sends out "get_vnc_console" > message to VM's related compute host > > 2. nova-compute, running on that compute host accepts that message, > generate a token and call libvirt driver's get_vnc_console methods. > > 3. Libvirt driver will connect with libvirt server to get VM's vnc port, > and look up the vnc host from FLAGS.vncserver_proxyclient_address. > > 4. nova-api will send out "authorize_console" message to nova-consoleauth, > which then caches the connection information returned by compute-node with > token as key > > 5. user browsers the URL returned the previous command, like below: > [root@robinlinux utils]# nova get-vnc-console myserver20 novnc > > +---+--+ > | Type | > Url| > > +---+--+ > | novnc | > http://controlnode:6080/vnc_auto.html?token=34ce7a44-6186-43d8-be14-2ea9e028b8fa| > > +---+--+ > > > 6. noVNC, which is listening on 6080 HTTP port, accepts the URL request, > sends out "check_token" message to nova-consoleauth > > 7. nova-consoleauth checks the cached connections and returns one > according to the requested token key > > 8. noVNC begins the proxy work, connecting the VNC server > About configuration items in nova.conf #read by nova-compute to > compose vnc-console URL > # for novnc > novncproxy_base_url=http://controlnode:6080/vnc_auto.html > # for xvpvnc > xvpvncproxy_base_url=http://controlnode:6081/console > #read by nova-compute to instantiate VMs > vncserver_listen=controlnode > > #read by libvirt driver to compute vnc-console URL > vncserver_proxyclient_address=controlnode > > > > -openstack-bounces+gongysh=cn.ibm@lists.launchpad.net wrote: - > > To: openstack@lists.launchpad.net > From: Nachi Ueno > > Sent by: openstack-bounces+gongysh=cn.ibm@lists.launchpad.net > Date: 04/13/2012 08:33AM > Subject: [Openstack] How to setup vncproxy with ubuntu precise package? > > Hi folks > > I'm trying to setup vncproxy with ubuntu package on precise. > But I could'nt find document how to setup them. > If you there are information, could you share me? > > Thank you in advance > Nachi > > ___ > 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] How to setup vncproxy with ubuntu precise package?
Hi folks I'm trying to setup vncproxy with ubuntu package on precise. But I could'nt find document how to setup them. If you there are information, could you share me? Thank you in advance Nachi ___ 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 2012.1 ("Essex") is RELEASED !
Wot!
2012/4/5 Chuck Short :
> Hi,
>
> We have packages available for Ubuntu Precise 12.04 now as well.
>
> Regards
> chuck
>
>
>
> On Thu, 5 Apr 2012 16:13:12 +
> Jim Curry wrote:
>
>> Congrats and thank you to everyone involved!
>>
>> On 4/5/12 10:30 AM, "Lloyd Dewolf" wrote:
>>
>> >w00t!
>> >
>> >
>> >On Thu, Apr 5, 2012 at 8:02 AM, Duncan McGreggor
>> > wrote:
>> >> Nicely done!
>> >>
>> >> Congratulations, everyone!!!
>> >>
>> >> d
>> >>
>> >> On Thu, Apr 5, 2012 at 10:52 AM, Thierry Carrez
>> >>
>> >>wrote:
>> >>> Hello everyone,
>> >>>
>> >>> I'm very happy to announce the immediate release of OpenStack
>> >>> 2012.1 (code-named "Essex"). This coordinated release contains 5
>> >>> components:
>> >>>
>> >>> OpenStack Compute ("Nova") 2012.1:
>> >>> https://launchpad.net/nova/essex/2012.1
>> >>>
>> >>> OpenStack Object Storage ("Swift") 1.4.8:
>> >>> https://launchpad.net/swift/essex/1.4.8
>> >>>
>> >>> OpenStack Image Service ("Glance") 2012.1:
>> >>> https://launchpad.net/glance/essex/2012.1
>> >>>
>> >>> OpenStack Identity ("Keystone") 2012.1:
>> >>> https://launchpad.net/keystone/essex/2012.1
>> >>>
>> >>> OpenStack Dashboard ("Horizon") 2012.1:
>> >>> https://launchpad.net/horizon/essex/2012.1
>> >>>
>> >>> You can find tarballs for download, as well as comprehensive
>> >>> lists of features and bugfixes, at the URLs above.
>> >>>
>> >>> You are strongly encouraged to read the Release Notes at:
>> >>> http://wiki.openstack.org/ReleaseNotes/Essex
>> >>>
>> >>> Enjoy!
>> >>>
>> >>> --
>> >>> Thierry Carrez (ttx)
>> >>> Release Manager, OpenStack
>> >>>
>> >>> ___
>> >>> 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
>> >
>> >
>> >
>> >--
>> >--
>> >@lloyddewolf
>> >http://www.pistoncloud.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
>
>
> ___
> 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] OpenStack Plugin for Jenkins
Justin++ This is really cool plugin. Good Job! 2012/4/4 Justin Santa Barbara : > I've created a quick OpenStack plugin for Jenkins, using the Java bindings > that Luis & I created. > > It's available on github here: > https://github.com/platformlayer/openstack-jenkins (no binaries - yet!) > > Right now, it has the same (jenkins) functionality as the S3 plugin; it can > store artifacts into Swift. I'm going to implement compute next so that we > can use OpenStack VMs to 'burst' building, like the EC2 plugin does. > > I'd love to hear from anyone that would be interested in using this, to > better understand what everyone wants. For example, the S3 plugin flattens > all directories when copying artifacts, that just seems wrong to me, so I'd > like to just fix it. > > Justin > > --- > > Justin Santa Barbara > Founder, FathomDB > > > > > ___ > 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] Ubuntu OpenStack QA Lab up and running
Hi Robbie Thank you for your quick reply. 2012/1/26 Robbie Williamson : > On 01/26/2012 02:49 PM, Nachi Ueno wrote: >> HI Robbie >> >> Awesome! >> Can I ask some questions? >> >> 1. Is there any document or opensource of your juju-based ci-deployment? > This is coming *real* soon, we just recently got it all working and > wanted to clean it up first. Cool! >> 2. Which kind of test are you running after deploy test? > I believe we're still at a very basic level right now, thus not much if > anything is ran after a deploy test. However, Adam and/or James can > answer this best (both cc'd). How about run tempest? OpenStack QA team is working on adding many integration test on that. https://launchpad.net/tempest https://github.com/openstack/tempest http://qa.openstack.org/integration.html Cheers Nati > -Robbie > >> >> Cheers >> Nati >> >> 2012/1/26 Robbie Williamson : >>> http://jenkins.qa.ubuntu.com/view/Precise%20OpenStack%20Testing/ >>> >>> James Page[1] has setup the jobs in the Ubuntu OpenStack QA Lab to start >>> publishing to our public Jenkins QA instance this morning. We now have >>> automated build testing of all core openstack components triggered from >>> upstream trunk commits. This is followed by automated deployment >>> (-deploy) of OpenStack in the lab with a serving of testing (-test) once >>> its all up and running. >>> >>> Credit to Adam Gandelman[2] for the Juju[3] charm work, deployment >>> framework and test execution and to Chuck Short[4] for the hugely >>> misnamed tarball.sh script which completes the git/bzr/packaging fu to >>> build and deploy openstack packages! >>> >>> The plan is to get the upstream Tempest test suite running in the lab; >>> at the moment we are running a more limited test script just to ensure >>> that you can spin up and instance and see it on the network. >>> >>> Ultimately, our plan is to leverage this testing to help us ensure a >>> stable and robust Ubuntu Cloud release in Ubuntu Server 12.04LTS. >>> >>> Comments and feedback are always welcome! >>> >>> Thanks, >>> -Robbie Williamson >>> >>> [1] https://launchpad.net/~james-page >>> [2] https://launchpad.net/~gandelman-a >>> [3] https://code.launchpad.net/charms >>> [4] https://launchpad.net/~zulcss >>> >>> -- >>> Robbie Williamson >>> robbiew[irc.freenode.net] >>> >>> "Don't make me angry...you wouldn't like me when I'm angry." >>> -Bruce Banner >>> >>> ___ >>> Mailing list: https://launchpad.net/~openstack >>> Post to : openstack@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~openstack >>> More help : https://help.launchpad.net/ListHelp > > > -- > Robbie Williamson > robbiew[irc.freenode.net] > > "Don't make me angry...you wouldn't like me when I'm angry." > -Bruce Banner ___ 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] Ubuntu OpenStack QA Lab up and running
HI Robbie Awesome! Can I ask some questions? 1. Is there any document or opensource of your juju-based ci-deployment? 2. Which kind of test are you running after deploy test? Cheers Nati 2012/1/26 Robbie Williamson : > http://jenkins.qa.ubuntu.com/view/Precise%20OpenStack%20Testing/ > > James Page[1] has setup the jobs in the Ubuntu OpenStack QA Lab to start > publishing to our public Jenkins QA instance this morning. We now have > automated build testing of all core openstack components triggered from > upstream trunk commits. This is followed by automated deployment > (-deploy) of OpenStack in the lab with a serving of testing (-test) once > its all up and running. > > Credit to Adam Gandelman[2] for the Juju[3] charm work, deployment > framework and test execution and to Chuck Short[4] for the hugely > misnamed tarball.sh script which completes the git/bzr/packaging fu to > build and deploy openstack packages! > > The plan is to get the upstream Tempest test suite running in the lab; > at the moment we are running a more limited test script just to ensure > that you can spin up and instance and see it on the network. > > Ultimately, our plan is to leverage this testing to help us ensure a > stable and robust Ubuntu Cloud release in Ubuntu Server 12.04LTS. > > Comments and feedback are always welcome! > > Thanks, > -Robbie Williamson > > [1] https://launchpad.net/~james-page > [2] https://launchpad.net/~gandelman-a > [3] https://code.launchpad.net/charms > [4] https://launchpad.net/~zulcss > > -- > Robbie Williamson > robbiew[irc.freenode.net] > > "Don't make me angry...you wouldn't like me when I'm angry." > -Bruce Banner > > ___ > 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] Unique key is case-sensitive or *in*sensitive?
Hi Jay Thanks Is it possible to do it on sqlalchemy.migration ? 2012/1/10 Jay Pipes : > +1 for Case Sensitive. For MySQL, this is a configuration issue. The > default character set and collation should use the *_cs variants. For > existing MySQL installations, an ALTER TABLE ... MODIFY COLUMN ... > CHARACTER SET ... COLLATION ... *_cs would need to be done for > affected tables. > > -jay > > On Tue, Jan 10, 2012 at 4:15 PM, Nachi Ueno > wrote: >> Hi folks >> >> Nova,Keystone,Glance uses RDBMS and they use unique key constraints. >> Nowadays, we can use Mysql,Sqlite,Postgresql. >> Unfortunately, the unique key behaviors of each DB are different. >> >> - Mysql : case-insensitive >> - Sqlite : case-sensitive >> - Postgresql : case-sensitive >> >> I wanna know the spec of OpenStack. >> Unique key is case-sensitive or *in*sensitive? >> >> Cheers >> Nati >> >> ___ >> 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] Unique key is case-sensitive or *in*sensitive?
Hi folks Nova,Keystone,Glance uses RDBMS and they use unique key constraints. Nowadays, we can use Mysql,Sqlite,Postgresql. Unfortunately, the unique key behaviors of each DB are different. - Mysql : case-insensitive - Sqlite : case-sensitive - Postgresql : case-sensitive I wanna know the spec of OpenStack. Unique key is case-sensitive or *in*sensitive? Cheers Nati ___ 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] Automatically confirmed after 24 hours on Resize API
Hi Biran Thank you for your reply. So this is a bug of the doc for now? 2011/12/27 Brian Waldon : > Hi Nachi! > > You are 100% correct, we have not yet implemented that in Nova. I don't see > any bugs/blueprints referencing this, so maybe if one was created we could > make sure it gets done. > > Thanks! > Brian > > On Dec 26, 2011, at 11:48 PM, Nachi Ueno wrote: > >> Hi folks >> >> The doc says *All resizes are automatically confirmed after 24 hours >> if they are not explicitly confirmed or reverted*, but I couldn't >> found such implementations. >> Is this a bug of Nova? or Is this a bug of doc? >> >> The resize function converts an existing server to a different flavor, >> in essence, scaling the server up or down. The original server is >> saved for a period of time to allow rollback if there is a problem. >> All resizes should be tested and explicitly confirmed, at which time >> the original server is removed. *All resizes are automatically >> confirmed after 24 hours if they are not explicitly confirmed or >> reverted*. >> >> http://docs.openstack.org/api/openstack-compute/1.1/content/Resize_Server-d1e3707.html >> >> Cheers >> Nachi Ueno >> >> ___ >> 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] Automatically confirmed after 24 hours on Resize API
Hi folks The doc says *All resizes are automatically confirmed after 24 hours if they are not explicitly confirmed or reverted*, but I couldn't found such implementations. Is this a bug of Nova? or Is this a bug of doc? The resize function converts an existing server to a different flavor, in essence, scaling the server up or down. The original server is saved for a period of time to allow rollback if there is a problem. All resizes should be tested and explicitly confirmed, at which time the original server is removed. *All resizes are automatically confirmed after 24 hours if they are not explicitly confirmed or reverted*. http://docs.openstack.org/api/openstack-compute/1.1/content/Resize_Server-d1e3707.html Cheers Nachi Ueno ___ 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] Gating on deployment and integration tests for stable/diablo
> Yes, our next focus will be on a post-commit integration test job for > trunk. That means we don't have to have all the technical problems > solved before we start testing trunk but we can draw attention to bugs. Super awesome!! Jim++ > > -Jim > > ___ > 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] Delete server spec
Hi Jessy Thanks. Hmm, there are no implementation of cleanup snapshot images. IMO, Snapshot image should not deleted, in case of API request mistake. https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L540 2011/12/7 Jesse Andrews : > I would interpret that to include the snapshots - but I'm not sure > that is what I'd expect as a user. > > On Wed, Dec 7, 2011 at 5:05 PM, Nachi Ueno > wrote: >> Hi folks >> >> I wanna make Delete server spec clear. >> >> The API doc says, >> "When a server is deleted, all images created from that server are also >> removed" >> >> http://docs.openstack.org/api/openstack-compute/1.1/content/Delete_Server-d1e2883.html >> >> IMO, "all images" is vm images which stored on compute node instances_path. >> Is this correct? >> >> Cheers >> Nati >> >> ___ >> 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] Delete server spec
Hi folks I wanna make Delete server spec clear. The API doc says, "When a server is deleted, all images created from that server are also removed" http://docs.openstack.org/api/openstack-compute/1.1/content/Delete_Server-d1e2883.html IMO, "all images" is vm images which stored on compute node instances_path. Is this correct? Cheers Nati ___ 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] API specifications
Hi folks >Anne Sorry,I remember now. I got extension docs from you. 2011/12/2 Brian Waldon : > accessIPv4 and accessIPv6 are both core instance attributes. The rest are all > attributes owned by existing extensions. Keep in mind that the spec doesn't > require all attributes to be returned in a POST response. I got it. So accessIPv4 and accessIPv6 is in core. The rest are extension. > Chris - I don't think config_drive is documented as an extension. This bug is > still not fixed: https://bugs.launchpad.net/nova/+bug/81 > > Waldon > > On Dec 2, 2011, at 1:13 PM, Christopher MacGown wrote: > >> Hi Nachi, >> >> At least for config_drive, it has been documented as an extension. >> >> - chris >> >> On Dec 2, 2011, at 10:07, Nachi Ueno wrote: >> >>> Hi Brian >>> >>> Thank you for your response. >>> How about params which is missing in docs? >>> >>> accessIPv4 >>> accessIPv6 >>> adminPass >>> config_drive >>> security_groups >>> networks >>> blob >>> keyname >>> availability_zone >>> reservation_id >>> min_count >>> max_count >>> 2011/12/1 Brian Waldon : >>>> Our consoles resource is not a part of the 1.1 (2.0) API. You are right in >>>> thinking it should be in the contrib directory. Additionally, it needs to >>>> be modified to act as an extension. >>>> >>>> Our current level of documentation of extensions is extremely lacking, so >>>> hopefully before Essex we can do a much better job. >>>> >>>> Brian Waldon >>>> >>>> >>>> On Dec 1, 2011, at 1:37 PM, Nachi Ueno wrote: >>>> >>>>> Hi Nova-cores >>>>> >>>>> Is the Console function in OS API 1.1 specs? >>>>> (See https://bugs.launchpad.net/nova/+bug/898266) >>>>> >>>>> The implementation is not in contrib directory, so it didn't looks an >>>>> extension. >>>>> But as 898266 mentioned, it is not described in API docs. >>>>> >>>>> And also, I checked API spces from code. (I know this is reverse way. :)) >>>>> >>>>> There are another example, >>>>> Create server could get, >>>>> >>>>> name (*) >>>>> imageRef (*) >>>>> flavorRef (*) >>>>> accessIPv4 >>>>> accessIPv6 >>>>> adminPass >>>>> config_drive >>>>> security_groups >>>>> networks >>>>> blob >>>>> keyname >>>>> availability_zone >>>>> reservation_id >>>>> min_count >>>>> max_count >>>>> metadata (*) >>>>> personality (*) >>>>> >>>>> And only * one is documented on API. >>>>> http://docs.openstack.org/api/openstack-compute/1.1/content/CreateServers.html >>>>> >>>>> Doc-Team can not decide specs, so I suppose Nova-core are responsible >>>>> to define these specs. >>>>> >>>>> Cheers >>>>> Nachi >>>>> >>>>> ___ >>>>> 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 > ___ 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] API specifications
Hi Gabe I got your point. However,I wanna know it is extension or not. Cheers Nati 2011/12/2 Gabe Westmaas : > Hi Nachi, > > The reason for excluding those from being required in the create response > is to allow us to make those creates as asynchronous as possible. > > Gabe > > On 12/2/11 12:01 PM, "Nachi Ueno" wrote: > >>Hi Brian >> >>Thank you for your response. >>How about params which is missing in docs? >> >>accessIPv4 >>accessIPv6 >>adminPass >>config_drive >>security_groups >>networks >>blob >>keyname >>availability_zone >>reservation_id >>min_count >>max_count >>2011/12/1 Brian Waldon : >>> Our consoles resource is not a part of the 1.1 (2.0) API. You are right >>>in thinking it should be in the contrib directory. Additionally, it >>>needs to be modified to act as an extension. >>> >>> Our current level of documentation of extensions is extremely lacking, >>>so hopefully before Essex we can do a much better job. >>> >>> Brian Waldon >>> >>> >>> On Dec 1, 2011, at 1:37 PM, Nachi Ueno wrote: >>> >>>> Hi Nova-cores >>>> >>>> Is the Console function in OS API 1.1 specs? >>>> (See https://bugs.launchpad.net/nova/+bug/898266) >>>> >>>> The implementation is not in contrib directory, so it didn't looks an >>>>extension. >>>> But as 898266 mentioned, it is not described in API docs. >>>> >>>> And also, I checked API spces from code. (I know this is reverse way. >>>>:)) >>>> >>>> There are another example, >>>> Create server could get, >>>> >>>> name (*) >>>> imageRef (*) >>>> flavorRef (*) >>>> accessIPv4 >>>> accessIPv6 >>>> adminPass >>>> config_drive >>>> security_groups >>>> networks >>>> blob >>>> keyname >>>> availability_zone >>>> reservation_id >>>> min_count >>>> max_count >>>> metadata (*) >>>> personality (*) >>>> >>>> And only * one is documented on API. >>>> >>>>http://docs.openstack.org/api/openstack-compute/1.1/content/CreateServer >>>>s.html >>>> >>>> Doc-Team can not decide specs, so I suppose Nova-core are responsible >>>> to define these specs. >>>> >>>> Cheers >>>> Nachi >>>> >>>> ___ >>>> 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 > ___ 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] API specifications
Hi Chris Sorry, I missed that. Would you give me url? Such as console.py, it is not in contrib directory. 2011/12/2 Christopher MacGown : > Hi Nachi, > > At least for config_drive, it has been documented as an extension. > > - chris > > On Dec 2, 2011, at 10:07, Nachi Ueno wrote: > >> Hi Brian >> >> Thank you for your response. >> How about params which is missing in docs? >> >> accessIPv4 >> accessIPv6 >> adminPass >> config_drive >> security_groups >> networks >> blob >> keyname >> availability_zone >> reservation_id >> min_count >> max_count >> 2011/12/1 Brian Waldon : >>> Our consoles resource is not a part of the 1.1 (2.0) API. You are right in >>> thinking it should be in the contrib directory. Additionally, it needs to >>> be modified to act as an extension. >>> >>> Our current level of documentation of extensions is extremely lacking, so >>> hopefully before Essex we can do a much better job. >>> >>> Brian Waldon >>> >>> >>> On Dec 1, 2011, at 1:37 PM, Nachi Ueno wrote: >>> >>>> Hi Nova-cores >>>> >>>> Is the Console function in OS API 1.1 specs? >>>> (See https://bugs.launchpad.net/nova/+bug/898266) >>>> >>>> The implementation is not in contrib directory, so it didn't looks an >>>> extension. >>>> But as 898266 mentioned, it is not described in API docs. >>>> >>>> And also, I checked API spces from code. (I know this is reverse way. :)) >>>> >>>> There are another example, >>>> Create server could get, >>>> >>>> name (*) >>>> imageRef (*) >>>> flavorRef (*) >>>> accessIPv4 >>>> accessIPv6 >>>> adminPass >>>> config_drive >>>> security_groups >>>> networks >>>> blob >>>> keyname >>>> availability_zone >>>> reservation_id >>>> min_count >>>> max_count >>>> metadata (*) >>>> personality (*) >>>> >>>> And only * one is documented on API. >>>> http://docs.openstack.org/api/openstack-compute/1.1/content/CreateServers.html >>>> >>>> Doc-Team can not decide specs, so I suppose Nova-core are responsible >>>> to define these specs. >>>> >>>> Cheers >>>> Nachi >>>> >>>> ___ >>>> 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 ___ 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] API specifications
Hi Brian Thank you for your response. How about params which is missing in docs? accessIPv4 accessIPv6 adminPass config_drive security_groups networks blob keyname availability_zone reservation_id min_count max_count 2011/12/1 Brian Waldon : > Our consoles resource is not a part of the 1.1 (2.0) API. You are right in > thinking it should be in the contrib directory. Additionally, it needs to be > modified to act as an extension. > > Our current level of documentation of extensions is extremely lacking, so > hopefully before Essex we can do a much better job. > > Brian Waldon > > > On Dec 1, 2011, at 1:37 PM, Nachi Ueno wrote: > >> Hi Nova-cores >> >> Is the Console function in OS API 1.1 specs? >> (See https://bugs.launchpad.net/nova/+bug/898266) >> >> The implementation is not in contrib directory, so it didn't looks an >> extension. >> But as 898266 mentioned, it is not described in API docs. >> >> And also, I checked API spces from code. (I know this is reverse way. :)) >> >> There are another example, >> Create server could get, >> >> name (*) >> imageRef (*) >> flavorRef (*) >> accessIPv4 >> accessIPv6 >> adminPass >> config_drive >> security_groups >> networks >> blob >> keyname >> availability_zone >> reservation_id >> min_count >> max_count >> metadata (*) >> personality (*) >> >> And only * one is documented on API. >> http://docs.openstack.org/api/openstack-compute/1.1/content/CreateServers.html >> >> Doc-Team can not decide specs, so I suppose Nova-core are responsible >> to define these specs. >> >> Cheers >> Nachi >> >> ___ >> 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] API specifications
Hi Nova-cores Is the Console function in OS API 1.1 specs? (See https://bugs.launchpad.net/nova/+bug/898266) The implementation is not in contrib directory, so it didn't looks an extension. But as 898266 mentioned, it is not described in API docs. And also, I checked API spces from code. (I know this is reverse way. :)) There are another example, Create server could get, name (*) imageRef (*) flavorRef (*) accessIPv4 accessIPv6 adminPass config_drive security_groups networks blob keyname availability_zone reservation_id min_count max_count metadata (*) personality (*) And only * one is documented on API. http://docs.openstack.org/api/openstack-compute/1.1/content/CreateServers.html Doc-Team can not decide specs, so I suppose Nova-core are responsible to define these specs. Cheers Nachi ___ 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] [nova-testing] Efforts for Essex
7;bug883293' > > 3) We now need to cherry-pick the two commits from above. I do so in > reverse order, as I want to apply the patch with the bug fix first and > then the patch with the test case: > > jpipes@uberbox:~/repos/nova$ git cherry-pick > 2a95311263cbda5886b9409284fea2d155b3cada > [bug883293 81e49b7] combination of log_notifier and > log.PublishErrorsHandler causes infinite loop Fixes bug 883293. > Author: Nachi Ueno > 1 files changed, 4 insertions(+), 0 deletions(-) > jpipes@uberbox:~/repos/nova$ git cherry-pick > 9cf5945c9e64d1c6a2eb6d9499e80d6c19aed058 > [bug883293 032f2c2] Add testcases for nova/log.py Fixes bug 883293. > Author: Nachi Ueno > 1 files changed, 66 insertions(+), 0 deletions(-) > > 4) OK, at this point, I have now applied the two commits against Essex > trunk. I now need to rebase against master, squash the two commits > into a single changeset, and ensure that a ChangeId is attached to the > rebased changeset: > > jpipes@uberbox:~/repos/nova$ git rebase -i master > > This opens up my editor. It shows the two commits from Nati on two > lines, both with the word "pick" at the beginning of each line. > > I squash the commits by changing the second line "pick" to "squash" > and change the first line "pick" to "reword". When I save and close, a > new editor window will open containing the commit messages of the > original two commits. I consolidate them into a single commit message > that references the bug # and save and close. If all goes well, you > will see something like this: > > [detached HEAD 37d3fbe] Fixes bug 883293. > Author: Nachi Ueno > 1 files changed, 4 insertions(+), 0 deletions(-) > [detached HEAD 95802c6] Fixes bug 883293. > Author: Nachi Ueno > 2 files changed, 70 insertions(+), 0 deletions(-) > Successfully rebased and updated refs/heads/bug883293. > > 5) Now all I need to do is push my changeset to Gerrit's trunk: > > jpipes@uberbox:~/repos/nova$ git review > Successfully rebased and updated refs/heads/bug883293. > Counting objects: 11, done. > Delta compression using up to 12 threads. > Compressing objects: 100% (5/5), done. > Writing objects: 100% (6/6), 1.59 KiB, done. > Total 6 (delta 5), reused 1 (delta 1) > remote: Resolving deltas: 0% (0/5) > remote: > remote: New Changes: > remote: https://review.openstack.org/1743 > remote: > To ssh://jaypi...@review.openstack.org:29418/openstack/nova.git > * [new branch] HEAD -> refs/for/master/bug/883293 > > ___ > 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] Bug fixes and test cases submitted against stable/diablo
Hi folks Thank you for your help > Mark and Jay and Reviewers I removed all review request for diablo/stable from Gerrit. And, We will follow community policy. Current our test code and bug fix is based on stable/diablo. For each branch. "forward-porting" is needed. 12 bug patch branch is in progress ( they are almost done) 34 bug patch branch is on github(*) 30 test code branch is on github. (*)https://github.com/ntt-pf-lab/nova/branches >From next work alter these branches, We will follow the policy (Essex first). However, for now, we have not enough man-power. So please help us. I wrote a script which shows bug description and conflict files and merge command. (See https://gist.github.com/1355816) Each branch is linked to bug report. If you guys help forward-porting work, would you please assign the bug for yourself. (Thanks Jay!) Naming rule in our repository is like this. https://github.com/ntt-pf-lab/nova/tree/openstack-qa-nova-(bugID) For now, There are bugs which is not fixed yet, so test code fails. So I think we should start from bug fix. Cheers Nati 2011/11/10 Jay Pipes : > On Wed, 2011-11-09 at 14:57 +0100, Thierry Carrez wrote: >> Soren Hansen wrote: >> > 2011/11/9 Nachi Ueno : >> >> I understand your point. Stop QAing stable/diablo and focus on Essex. >> > >> > Oh, no no. That's not the point. I'm thrilled to have you work on >> > QAing Diablo. The only issue is that the fixes you come up with should >> > be pushed to Essex first. There are two reasons for this: >> > >> > * If we don't push the fixes to Essex, the problems will still be >> > present in Essex and every release after that. >> > >> > * Having them in Essex lets us try them out, vet them and validate >> > them more thoroughly before we let them into the stable branch. When a >> > patch lands in the stable branch it has to be well tested already >> > (unless of course Essex has deviated too much, in which case we'll >> > have to accept the risk of getting it into Diablo directly). >> >> +1 >> >> You should submit patches to master and then backport them to >> stable/diablo, rather than proposing them for stable/diablo directly. >> That ensures your work benefits both branches: making diablo better >> without making essex worse than diablo. >> >> If that's just too much work, maybe you should raise the issue at the >> next QA meeting to try to get some outside help ? > > At the QA meeting yesterday, I offered my help to Nati. I will handle > proposing his patches to Essex up to a future date where Nati and his > team will switch to code against Essex, not Diablo/stable and propose > first to master, then others will backport to diablo/stable. > > Nati and I will decide on that future date for his team to switch their > focus to Essex trunk and not have to have someone manually > "forward-port" these patches to trunk. > > Cheers, > -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 > ___ 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] Bug fixes and test cases submitted against stable/diablo
Hi Mark Thank you for your sharing discussion. # hmm, If I could create new instance of me, problem will be fixed. I understand your point. Stop QAing stable/diablo and focus on Essex. Ideally, we should focus on upstream branch. Ideally, we can start use the code after release out. However the current situation is different. IMO the quality diablo is not ready for real deployment. In the diablo summit, I think we agreed the policy "Do not decrease code coverage on merge". But it is not applied through diablo timeframe,and the diablo has small coverage. And for essex, the specs are changing, so it is quite difficult QA by non-implementer. In addition, to wait 6 month is not allowed for my team. So QAing stable/branch with fixed specs is very important. Our contribution is 1000 unit test cases for stable/diablo nova, and bug patch (I'm not sure all test could be used for Essex) #Sorry i sent wrong number for you. There test cases found about 60 bugs. And also we are writing each bag patch. https://bugs.launchpad.net/nova/+bugs?search=Search&field.bug_reporter=nati-ueno For test case, it didn't have bad effect for code. Otherwise they helps keep quality of code. No violation for (1). So I think it should be merged to stable/diablo. For bug patch, it should be discussed case-by-case. Some large refactoring have done already for Essex,then some bugs are fixed on the refactoring. We are struggling with very tight schedule. X( If our contribution is rejected to the stable/diablo, to maintain our own branch is only option for us. And I don't really want to do this. 2011/11/8 Mark McLoughlin : > Hi Nati > > (Restarting our offline discussion here ...) > > I see you've proposed a stack of changes to Nova. Nice work! Kudos! > > > https://review.openstack.org/#q,status:open+project:openstack/nova+branch:stable/diablo+owner:nati,n,z > > However, they shouldn't be submitted against the stable/diablo branch. > If they were just merged there, they would never make it into the Essex > and later releases. > > The policy for what is acceptable in the stable branch is documented > here: > > http://wiki.openstack.org/StableBranch > > The policy is pretty standard practice for stable branches and the > reasons for it include: > > 1) We try and reduce the risk of regressions on the stable branch to > the absolute minimum. We also try to reduce the size and number of > changes so that people using the stable branch can be confident > that the risk of the changes is low and they can review the > changes themselves. > > 2) Getting fixes onto the main development branch before applying > them to the stable branch means we have a good chance of catching > any regressions caused by the fix on master before it has a chance > to cause a regression on the stable branch. > > 3) But most importantly, the policy is there to ensure that people > don't focus on stable branches to the detriment of the development > branch. If everyone focused their effort on fixing the stable > branch and never included those fixes in the development branch, > every new release would be in terrible shape and the fixing effort > would have to start over again. > > I think you're in the situation that (3) is trying to prevent. > > i.e. you and your team are focused on testing and fixing Diablo and > don't have the time to submit your fixes against Essex. While it's great > to see your fixes, IMHO you really need to think longer term. > > If you leave it until later to rebase the fixes onto master, you'll > probably find it to be very difficult and may never complete the rebase. > And if you never complete the rebase, all your effort is essentially > wasted in the long term. > > I think most of the Linux distributors learnt this lesson the hard way > over the years and now have an "upstream first" policy. Hopefully we can > save you the pain of dealing a similar mess when Essex comes out! :-) > > Thanks, > Mark. > > ___ 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] Bug fixes and test cases submitted against stable/diablo
Hi Mark Thank you for your sharing discussion. # hmm, If I could create new instance of me, problem will be fixed. I understand your point. Stop QAing stable/diablo and focus on Essex. Ideally, we should focus on upstream branch. Ideally, we can start use the code after release out. However the current situation is different. IMO the quality diablo is not ready for real deployment. In the diablo summit, I think we agreed the policy "Do not decrease code coverage on merge". But it is not applied through diablo timeframe,and the diablo has small coverage. And for essex, the specs are changing, so it is quite difficult QA by non-implementer. In addition, to wait 6 month is not allowed for my team. So QAing stable/branch with fixed specs is very important. Our contribution is 1000 unit test cases for stable/diablo nova, and bug patch (I'm not sure all test could be used for Essex) #Sorry i sent wrong number for you. There test cases found about 60 bugs. And also we are writing each bag patch. https://bugs.launchpad.net/nova/+bugs?search=Search&field.bug_reporter=nati-ueno For test case, it didn't have bad effect for code. Otherwise they helps keep quality of code. No violation for (1). So I think it should be merged to stable/diablo. For bug patch, it should be discussed case-by-case. Some large refactoring have done already for Essex,then some bugs are fixed on the refactoring. We are struggling with very tight schedule. X( If our contribution is rejected to the stable/diablo, to maintain our own branch is only option for us. And I don't really want to do this. 2011/11/8 Mark McLoughlin : > Hi Nati > > (Restarting our offline discussion here ...) > > I see you've proposed a stack of changes to Nova. Nice work! Kudos! > > > https://review.openstack.org/#q,status:open+project:openstack/nova+branch:stable/diablo+owner:nati,n,z > > However, they shouldn't be submitted against the stable/diablo branch. > If they were just merged there, they would never make it into the Essex > and later releases. > > The policy for what is acceptable in the stable branch is documented > here: > > http://wiki.openstack.org/StableBranch > > The policy is pretty standard practice for stable branches and the > reasons for it include: > > 1) We try and reduce the risk of regressions on the stable branch to > the absolute minimum. We also try to reduce the size and number of > changes so that people using the stable branch can be confident > that the risk of the changes is low and they can review the > changes themselves. > > 2) Getting fixes onto the main development branch before applying > them to the stable branch means we have a good chance of catching > any regressions caused by the fix on master before it has a chance > to cause a regression on the stable branch. > > 3) But most importantly, the policy is there to ensure that people > don't focus on stable branches to the detriment of the development > branch. If everyone focused their effort on fixing the stable > branch and never included those fixes in the development branch, > every new release would be in terrible shape and the fixing effort > would have to start over again. > > I think you're in the situation that (3) is trying to prevent. > > i.e. you and your team are focused on testing and fixing Diablo and > don't have the time to submit your fixes against Essex. While it's great > to see your fixes, IMHO you really need to think longer term. > > If you leave it until later to rebase the fixes onto master, you'll > probably find it to be very difficult and may never complete the rebase. > And if you never complete the rebase, all your effort is essentially > wasted in the long term. > > I think most of the Linux distributors learnt this lesson the hard way > over the years and now have an "upstream first" policy. Hopefully we can > save you the pain of dealing a similar mess when Essex comes out! :-) > > Thanks, > Mark. > > ___ 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] Permission denied (publickey) by gerrit
Hi folks I got permission denied from gerrit. Does Anyone know the solution? nova@nova-VirtualBox:~$ ssh -p29418 -o StrictHostKeyChecking=no nati-u...@review.openstack.org gerrit ls-projects Permission denied (publickey). It looks my ssh-pub-key is not configured on gerrit server. I added my pub key for both of review.openstack.org and launchpad. Thank you in advance Nachi ___ 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] Branch coverage
Hi openstackers Coverage 3.4 supports branch a coverage feature now. http://nedbatchelder.com/code/coverage/branch.html We can use it on nose using dstanekcom-python-nose branch. I run it for nova. (See wiki page) http://wiki.openstack.org/branch_coverage # You can download a result of branch coverage. Is it possible to let http://jenkins.openstack.org/ support branch coverage? This feature helps QA of nova. Regards, Nachi Ueno ___ 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] Testing
Hello Vish. I would like to support testing effort. I wrote an example very basic unit test doc and some tips how to use pudb and nose-pudb. http://etherpad.openstack.org/diablo-testing Regards Nachi Ueno NTT ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
