Re: [openstack-dev] [Devstack] Can't start service nova-novncproxy
That's' the most confusing part. I don't even have a log for service nova-novncproxy. Thanks. -chen -Original Message- From: Kashyap Chamarthy [mailto:kcham...@redhat.com] Sent: Monday, March 02, 2015 12:16 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Devstack] Can't start service nova-novncproxy On Sat, Feb 28, 2015 at 06:20:54AM +, Li, Chen wrote: Hi all, I'm trying to install a fresh all-in-one openstack environment by devstack. After the installation, all services looks well, but I can't open instance console in Horizon. I did a little check, and found service nova-novncproxy was not started ! What do you see in your 'screen-n-vnc.log' (I guess) log? I don't normally run Horizon or nova-vncproxy (only n-cpu, n-sch, n-cond), these are the ENABLED_SERVICES in my minimal DevStack config (Nova, Neutron, Keystone and Glance): ENABLED_SERVICES=g-api,g-reg,key,n-api,n-cpu,n-sch,n-cond,mysql,rabbit,dstat,quantum,q-svc,q-agt,q-dhcp,q-l3,q-meta [1] https://kashyapc.fedorapeople.org/virt/openstack/2-minimal_devstack_localrc.conf Anyone has idea why this happened ? Here is my local.conf : http://paste.openstack.org/show/183344/ My os is: Ubuntu 14.04 trusty 3.13.0-24-generic -- /kashyap __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] auto-abandon changesets considered harmful (was Re: [stable][all] Revisiting the 6 month release cycle [metrics])
+2 I recently had a patch abandoned that had every right to be pulled off the list. It had fallen off my radar and was no longer relevant. As long as there is a way to restore the patch where appropriate, we should do it. Jay I have to agree with John. We have many more submitters than we have core folks, and our current scaling limits tend to be around core and reviews, not around submissions, so making life slightly more difficult for submitters in order to make it substantially easier for core is a reasonable trade. Not marking a review as abandoned if feedback hasn't been responded to in 2 week misleads reviewers and submitters, so I fully support the cinder abandonment rules - the 'restore change' button takes a moment to click. On 28 February 2015 at 03:02, John Griffith john.griffi...@gmail.com wrote: On Fri, Feb 27, 2015 at 5:40 PM, Stefano Maffulli stef...@openstack.org wrote: I'm not expressing myself cleary enough. I don't advocate for the removal of anything because I like pretty charts. I'm changing the subject to be even more clear. On Fri, 2015-02-27 at 13:26 -0800, James E. Blair wrote: I am asking you to please independently remove changes that you don't think should be considered from your metrics. I'm saying that the reports have indicators that seem to show struggle. In a previous message Kevin hinted that probably a reason for those bad looking numbers was due to a lot of reviews that appear to have been abandoned. This doesn't seem the case because some projects have a habit of 'purging'. I have never explicitly ordered developers to purge anything. If their decision to purge is due to the numbers they may have seen on the reports I'd like to know. That said, the problem that the reports highlight remains confirmed so far: contributors seem to be left in some cases hanging, for many many days, *after a comment* and they don't come back. I think abandoning changes so that the metrics look the way we want is a terrible experience for contributors. I agree, that should not be a motivator. Also, after chatting with you on IRC I tend to think that instead of abandoning the review we should highlight them and have humans act on them. Maybe build a dashboard of 'old stuff' to periodically sift through and see if there are things worth picking up again or to ping the owner or something else managed by humans. I happened to have found one of such review automatically closed that could have been fixed with a trivial edit in commit message instead: https://review.openstack.org/#/c/98735/ (that owner had a bunch of auto-abandoned patches https://review.openstack.org/#/q/owner:%22Mh+Raies+%253Craiesmh08% 2540gmail.com%253E%22,n,z https://review.openstack.org/#/q/owner:%22Mh+Raies+%253Craiesmh08%2540gmail.com%253E%22,n,z). I have made a note to reach out to him and get more anecdotes. Especially as it appears some projects, such as nova, are in a position where they are actually leaving -2 votes on changes which will not be lifted for 2 or 3 months. That means that if someone runs a script like Sean's, these changes will be abandoned, yet there is nothing that the submitter can do to progress the change in the mean time. Abandoning such a review is making an already bad experience for contributors even worse. this sounds like a different issue :( __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev For what it's worth, at one point the Cinder project setup an auto-abandon job that did purge items that had a negative mark either from a reviewer or from Jenkins and had not been updated in over two weeks. This had absolutely nothing to do with metrics or statistical analysis of the project. We simply had a hard time dealing with patches that the submitter didn't care about. If somebody takes the time to review a patch, then I don't think it's too much to ask that the submitter respond to questions or comments within a two week period. Note, the auto purge in our case only purged items that had no updates or activity at all. We were actually in a position where we had patches that were submitted, failed unit tests in the gate (valid failures that occurred 100% of the time) and had sat for an entire release without the submitter ever updating the patch. I don't think it's unreasonable at all to abandon these and remove them from the queue. I don't think this is a bad thing, I think it's worse to leave them as active when they're bit-rotted and the submitter doesn't even care about them any longer. The other thing is, those patches are still there, they can still be accessed and reinstated. There's a lot of knocks against core teams regarding time to review and keeping
Re: [openstack-dev] [Ironic] Adding vendor drivers in Ironic
Hi, I am just relaying pain-points that we encountered in neutron. As I have said below it makes the development process a lot quicker for people working on external drivers. I personally believe that it fragments the community and feel that the external drivers loose the community contributions and inputs. Thanks Gary On 2/28/15, 7:58 PM, Clint Byrum cl...@fewbar.com wrote: I'm not sure I understand your statement Gary. If Ironic defines what is effectively a plugin API, and the vendor drivers are careful to utilize that API properly, the two sets of code can be released entirely independent of one another. This is how modules work in the kernel, X.org drivers work, and etc. etc. Of course, vendors could be irresponsible and break compatibility with older releases of Ironic, but that is not in their best interest, so I don't see why anybody would need to tightly couple. As far as where generic code goes, that seems obvious: it all has to go into Ironic and be hidden behind the plugin API. Excerpts from Gary Kotton's message of 2015-02-28 09:28:55 -0800: Hi, There are pros and cons for what you have mentioned. My concern, and I mentioned them with the neutron driver decomposition, is that we are are loosing the community inputs and contributions. Yes, one can certainly move faster and freer (which is a huge pain point in the community). How are generic code changes percolated to your repo? Do you have an automatic CI that detects this? Please note that when itonic release you will need to release your repo so that the relationship is 1:1... Thanks Gary From: Ramakrishnan G rameshg87.openst...@gmail.commailto:rameshg87.openst...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.o rg Date: Saturday, February 28, 2015 at 8:28 AM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.o rg Subject: [openstack-dev] [Ironic] Adding vendor drivers in Ironic Hello All, This is about adding vendor drivers in Ironic. In Kilo, we have many vendor drivers getting added in Ironic which is a very good thing. But something I noticed is that, most of these reviews have lots of hardware-specific code in them. This is something most of the other Ironic folks cannot understand unless they go and read the hardware manuals of the vendor hardware about what is being done. Otherwise we just need to blindly mark the file as reviewed. Now let me pitch in with our story about this. We added a vendor driver for HP Proliant hardware (the *ilo drivers in Ironic). Initially we proposed this same thing in Ironic that we will add all the hardware specific code in Ironic itself under the directory drivers/modules/ilo. But few of the Ironic folks didn't agree on this (Devananda especially who is from my company :)). So we created a new module proliantutils, hosted in our own github and recently moved it to stackforge. We gave a limited set of APIs for Ironic to use - like get_host_power_status(), set_host_power(), get_one_time_boot(), set_one_time_boot(), etc. (Entire list is here https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackforg e_proliantutils_blob_master_proliantutils_ilo_operations.pyd=AwICAgc=Sq cl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9 N3-diTlNj4GyNcm=QRyrevJwoHB6GFxiTDorDRShZ79rnf-SwtdVwGiYfccs=e9_q3eOLqT eI3oNwT_0fur3qzpFLUy9wxVPEjujfAMse= https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackfor ge_proliantutils_blob_master_proliantutils_ilo_operations.pyd=AwMFaQc=S qcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq 9N3-diTlNj4GyNcm=m5_FxZnmz3 cyIvavSV DImH6xLR79L-svbcYKkjdcnb8s=fjlOB2ORYcne-cyYnZJO8bdpi4J8rbfCAbmciPllmFIe= ). We have only seen benefits in doing it. Let me bring in some examples: 1) We tried to add support for some lower version of servers. We could do this without making any changes in Ironic (Review in proliantutils https://review.openstack.org/#/c/153945/) 2) We are adding support for newer models of servers (earlier we use to talk to servers in protocol called RIBCL, newer servers we will use a protocol called RIS) - We could do this with just 14 lines of actual code change in Ironic (this was needed mainly because we didn't think we will have to use a new protocol itself when we started) - https://review.openstack.org/#/c/154403/ Now talking about the advantages of putting hardware-specific code in Ironic: 1) It's reviewed by Openstack community and tested: No. I doubt if I throw in 600 lines of new iLO specific code that is here (https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackfor ge_proliantutils_blob_master_proliantutils_ilo_ris.pyd=AwICAgc=Sqcl0Ez6 M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diT lNj4GyNcm=QRyrevJwoHB6GFxiTDorDRShZ79rnf-SwtdVwGiYfccs=tEA3ZOH2Gu6GxHBG PfPB0x9LeHuMcYAcDbqbQyPVHZAe=
Re: [openstack-dev] [Manila] Ceph native driver for manila
Am 27.02.2015 um 01:04 schrieb Sage Weil: [sorry for ceph-devel double-post, forgot to include openstack-dev] Hi everyone, The online Ceph Developer Summit is next week[1] and among other things we'll be talking about how to support CephFS in Manila. At a high level, there are basically two paths: We discussed the CephFS Manila topic also on the last Manila Midcycle Meetup (Kilo) [1][2] 2) Native CephFS driver As I currently understand it, - The driver will set up CephFS auth credentials so that the guest VM can mount CephFS directly - The guest VM will need access to the Ceph network. That makes this mainly interesting for private clouds and trusted environments. - The guest is responsible for running 'mount -t ceph ...'. - I'm not sure how we provide the auth credential to the user/guest... The auth credentials need to be handled currently by a application orchestration solution I guess. I see currently no solution on the Manila layer level atm. If Ceph would provide OpenStack Keystone authentication for rados/cephfs instead of CephX, it could be handled via app orch easily. This would perform better than an NFS gateway, but there are several gaps on the security side that make this unusable currently in an untrusted environment: - The CephFS MDS auth credentials currently are _very_ basic. As in, binary: can this host mount or it cannot. We have the auth cap string parsing in place to restrict to a subdirectory (e.g., this tenant can only mount /tenants/foo), but the MDS does not enforce this yet. [medium project to add that] - The same credential could be used directly via librados to access the data pool directly, regardless of what the MDS has to say about the namespace. There are two ways around this: 1- Give each tenant a separate rados pool. This works today. You'd set a directory policy that puts all files created in that subdirectory in that tenant's pool, then only let the client access those rados pools. 1a- We currently lack an MDS auth capability that restricts which clients get to change that policy. [small project] 2- Extend the MDS file layouts to use the rados namespaces so that users can be separated within the same rados pool. [Medium project] 3- Something fancy with MDS-generated capabilities specifying which rados objects clients get to read. This probably falls in the category of research, although there are some papers we've seen that look promising. [big project] Anyway, this leads to a few questions: - Who is interested in using Manila to attach CephFS to guest VMs? - What use cases are you interested? - How important is security in your environment? As you know we (Deutsche Telekom) are may interested to provide shared filesystems via CephFS to VMs instead of e.g. via NFS. We can provide/discuss use cases at CDS. For us security is very critical, as the performance is too. The first solution via ganesha is not what we prefer (to use CephFS via p9 and NFS would not perform that well I guess). The second solution, to use CephFS directly to the VM would be a bad solution from the security point of view since we can't expose the Ceph public network directly to the VMs to prevent all the security issues we discussed already. We discussed during the Midcycle a third option: Mount CephFS directly on the host system and provide the filesystem to the VMs via p9/virtfs. This need nova integration (I will work on a POC patch for this) to setup libvirt config correctly for virtfs. This solve the security issue and the auth key distribution for the VMs, but it may introduces performance issues due to virtfs usage. We have to check what the specific performance impact will be. Currently this is the preferred solution for our use cases. What's still missing in this solution is user/tenant/subtree separation as in the 2th option. But this is needed anyway for CephFS in general. Danny [1] https://etherpad.openstack.org/p/manila-kilo-midcycle-meetup [2] https://etherpad.openstack.org/p/manila-meetup-winter-2015 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Hyper-V Nova CI Infrastructure
Hello, OpenStack dev members, Is there any problem on Hyper-V Nova CI Infrastructure? I don't know why i failed my petch set. My first patch set was succeeded , and then i changed the commit message, then failed on Hyper-V test. Could you tell me the reason? Here is my test result links. http://64.119.130.115/156126/4/ Thanks Kwonho __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] auto-abandon changesets considered harmful (was Re: [stable][all] Revisiting the 6 month release cycle [metrics])
On 28/02/15 09:02, John Griffith wrote: On Fri, Feb 27, 2015 at 5:40 PM, Stefano Maffulli stef...@openstack.org mailto:stef...@openstack.org wrote: I'm not expressing myself cleary enough. I don't advocate for the removal of anything because I like pretty charts. I'm changing the subject to be even more clear. On Fri, 2015-02-27 at 13:26 -0800, James E. Blair wrote: I am asking you to please independently remove changes that you don't think should be considered from your metrics. I'm saying that the reports have indicators that seem to show struggle. In a previous message Kevin hinted that probably a reason for those bad looking numbers was due to a lot of reviews that appear to have been abandoned. This doesn't seem the case because some projects have a habit of 'purging'. I have never explicitly ordered developers to purge anything. If their decision to purge is due to the numbers they may have seen on the reports I'd like to know. That said, the problem that the reports highlight remains confirmed so far: contributors seem to be left in some cases hanging, for many many days, *after a comment* and they don't come back. I think abandoning changes so that the metrics look the way we want is a terrible experience for contributors. I agree, that should not be a motivator. Also, after chatting with you on IRC I tend to think that instead of abandoning the review we should highlight them and have humans act on them. Maybe build a dashboard of 'old stuff' to periodically sift through and see if there are things worth picking up again or to ping the owner or something else managed by humans. I happened to have found one of such review automatically closed that could have been fixed with a trivial edit in commit message instead: https://review.openstack.org/#/c/98735/ (that owner had a bunch of auto-abandoned patches https://review.openstack.org/#/q/owner:%22Mh+Raies+%253Craiesmh08% 2540gmail.com%253E%22,n,z https://review.openstack.org/#/q/owner:%22Mh+Raies+%253Craiesmh08% 2540gmail.com%253E%22,n,z). I have made a note to reach out to him and get more anecdotes. Especially as it appears some projects, such as nova, are in a position where they are actually leaving -2 votes on changes which will not be lifted for 2 or 3 months. That means that if someone runs a script like Sean's, these changes will be abandoned, yet there is nothing that the submitter can do to progress the change in the mean time. Abandoning such a review is making an already bad experience for contributors even worse. this sounds like a different issue :( __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev For what it's worth, at one point the Cinder project setup an auto-abandon job that did purge items that had a negative mark either from a reviewer or from Jenkins and had not been updated in over two weeks. This had absolutely nothing to do with metrics or statistical analysis of the project. We simply had a hard time dealing with patches that the submitter didn't care about. If somebody takes the time to review a patch, then I don't think it's too much to ask that the submitter respond to questions or comments within a two week period. Note, the auto purge in our case only purged items that had no updates or activity at all. We were actually in a position where we had patches that were submitted, failed unit tests in the gate (valid failures that occurred 100% of the time) and had sat for an entire release without the submitter ever updating the patch. I don't think it's unreasonable at all to abandon these and remove them from the queue. I don't think this is a bad thing, I think it's worse to leave them as active when they're bit-rotted and the submitter doesn't even care about them any longer. The other thing is, those patches are still there, they can still be accessed and reinstated. There's a lot of knocks against core teams regarding time to review and keeping up with the work load.. that's fine, but at the same time if you submit something you should follow through on it and respond to comments or test failures in a timely manner. Also there should be some scaling factor here; if a patch that needs updating should be expected to be able to sit in the queue for a month for example, then we should give one month for each reviewer; so minimum of three months for a +1, +2 and +A. I don't think it's
Re: [openstack-dev] [cinder][horizon]Proper error handling/propagation to UI
Deleting a volume created from a snapshot is permitted. Performing operations on a volume created from snapshot should have the same behavior as volumes created from volumes, images, or empty (no source). In all of these cases, the volume should be deleted, regardless of where it came from. Independence from source is one of the differences between volumes and snapshots in Cinder. The driver must take care to ensure this. As to your question about propagating errors without changing an object's state, that is unfortunately not doable in Cinder today (or any other OpenStack project as far as I know). The object's state is currently the only mechanism for reporting an operation's success or failure. On Sun, Mar 1, 2015 at 6:07 PM, Duncan Thomas duncan.tho...@gmail.com wrote: I thought that case should be caught well before it gets to the driver. Can you retry with the LVM driver please? On 27 February 2015 at 10:48, Eduard Matei eduard.ma...@cloudfounders.com wrote: Hi, We've been testing our cinder driver extensively and found a strange behavior in the UI: - when trying to delete a snapshot that has clones (created volume from snapshot) and error is raised in our driver which turns into error_deleting in cinder and the UI; further actions on that snapshot are impossible from the ui, the user has to go to CLI and do cinder snapshot-reset-state to be able to delete it (after having deleted the clones) - to help with that we implemented a check in the driver and now we raise exception.SnapshotIsBusy; now the snapshot remains available (as it should be) but no error bubble is shown in the UI (only the green one: Success. Scheduled deleting of...). So the user has to go to c-vol screen and check the cause of the error So question: how should we handle this so that a. The snapshot remains in state available b. An error bubble is shown in the UI stating the cause. Thanks, Eduard -- *Eduard Biceri Matei, Senior Software Developer* www.cloudfounders.com | eduard.ma...@cloudfounders.com *CloudFounders, The Private Cloud Software Company* Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee or an employee or agent responsible for delivering this message to the named addressee, you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this email in error we request you to notify us by reply e-mail and to delete all electronic files of the message. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the content of this message, and shall have no liability for any loss or damage suffered by the user, which arise as a result of e-mail transmission. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Avishay Traeger* *Storage RD* Mobile: +972 54 447 1475 E-mail: avis...@stratoscale.com Web http://www.stratoscale.com/ | Blog http://www.stratoscale.com/blog/ | Twitter https://twitter.com/Stratoscale | Google+ https://plus.google.com/u/1/b/108421603458396133912/108421603458396133912/posts | Linkedin https://www.linkedin.com/company/stratoscale __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [devstack] pip wheel' requires the 'wheel' package
Hello, I got an error when try to ./stack.sh as: /2015-03-02 05:58:20.692 | net.ipv4.ip_local_reserved_ports = 35357,35358 2015-03-02 05:58:20.959 | New python executable in tmp-venv-NoMO/bin/python 2015-03-02 05:58:22.056 | Installing setuptools, pip...done. 2015-03-02 05:58:22.581 | ERROR: 'pip wheel' requires the 'wheel' package. To fix this, run: pip install wheel/ After pip install wheel, got same error. In [2]: wheel.__path__ Out[2]: ['/usr/local/lib/python2.7/dist-packages/wheel'] In [5]: pip.__path__ Out[5]: ['/usr/local/lib/python2.7/dist-packages/pip'] $ which python /usr/bin/python As above, the wheel can be imported successfully, any hints ? Thanks. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [devstack] pip wheel' requires the 'wheel' package
From: yuntong [mailto:yuntong...@gmail.com] Sent: Monday, March 2, 2015 7:35 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [devstack] pip wheel' requires the 'wheel' package Hello, I got an error when try to ./stack.sh as: 2015-03-02 05:58:20.692 | net.ipv4.ip_local_reserved_ports = 35357,35358 2015-03-02 05:58:20.959 | New python executable in tmp-venv-NoMO/bin/python 2015-03-02 05:58:22.056 | Installing setuptools, pip...done. 2015-03-02 05:58:22.581 | ERROR: 'pip wheel' requires the 'wheel' package. To fix this, run: pip install wheel After pip install wheel, got same error. In [2]: wheel.__path__ Out[2]: ['/usr/local/lib/python2.7/dist-packages/wheel'] In [5]: pip.__path__ Out[5]: ['/usr/local/lib/python2.7/dist-packages/pip'] $ which python /usr/bin/python As above, the wheel can be imported successfully, any hints ? Thanks. Did you try pip install –upgrade wheel ? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] 答复: [Heat] Stepping down from core
Good lucky :) -邮件原件- 发件人: Jeff Peeler [mailto:jpee...@redhat.com] 发送时间: 2015年2月28日 4:23 收件人: openstack-dev@lists.openstack.org 主题: [openstack-dev] [Heat] Stepping down from core As discussed during the previous Heat meeting, I'm going to be stepping down from core on the Heat project. My day to day focus is going to be more focused on TripleO for the foreseeable future, and I hope to be able to soon focus on reviews there. Being part of Heat core since day 0 has been a good experience, but keeping up with multiple projects is a lot to manage. I don't know how some of you do it! Jeff __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Stepping down from core
Thank you for the great contribution. Good luck in your new endeavors :) Regards, Sergey. On 27 February 2015 at 23:23, Jeff Peeler jpee...@redhat.com wrote: As discussed during the previous Heat meeting, I'm going to be stepping down from core on the Heat project. My day to day focus is going to be more focused on TripleO for the foreseeable future, and I hope to be able to soon focus on reviews there. Being part of Heat core since day 0 has been a good experience, but keeping up with multiple projects is a lot to manage. I don't know how some of you do it! Jeff __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] volume's current host in retype [cinder]
Hi, i was trying to understand below patch: https://review.openstack.org/#/c/44881/24 What volume's current host means in this patch? I want to understand it with some examples. Regards Nikesh __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] what code in cinder volume driver supports volume migration between two backends of same type but having different volume types? [cinder]
Please do feel free to write a patch - you can probably do the best job, given that the questions are still fresh in your mind. On 1 March 2015 at 21:37, Nikesh Kumar Mahalka nikeshmaha...@vedams.com wrote: Thanks, I think if these informations are added in openstack documents having topic volume migration then it would be good for new folks in cinder. Regards Nikesh On Sun, Mar 1, 2015 at 10:12 PM, Duncan Thomas duncan.tho...@gmail.com wrote: Migrate - move between backends of the same volume type Retype - move between types. Will migrate the volume for you if necessary On 1 March 2015 at 09:40, Avishay Traeger avis...@stratoscale.com wrote: Nikesh, The case you are trying is supposed to fail. You have a volume of type dothill_realstor1 which is defined to say this volume must be on backend DotHill_RealStor1. This is a requirement that you defined for that volume. Now you want to migrate it to realstor2, which is a violation of the requirement that you specified. To migrate it, you should change the volume type (retype), which changes the requirement. Thanks, Avishay On Sat, Feb 28, 2015 at 11:02 AM, Nikesh Kumar Mahalka nikeshmaha...@vedams.com wrote: I tried below link for volume migration on my driver and also similar efforts for LVM. Even whatever documents available in openstack for volume-migration,each one showing volume migration of a volume having volume type None I added host assisted volume migration function in my cinder driver. When i am trying volume migration on a volume without volume type,then my volume migration function is getting called and i am able to do volume migration. But when i am trying volume migration on a volume having volume type,then my volume migration function is not getting called. http://paste.openstack.org/show/183392/ http://paste.openstack.org/show/183405/ On Tue, Jan 20, 2015 at 12:31 AM, Nikesh Kumar Mahalka nikeshmaha...@vedams.com wrote: do cinder retype (v2) works for lvm? How to use cinder retype? I tried for volume migration from one volume-type LVM backend to another volume-type LVM backend.But its failed. How can i acheive this? Similarly i am writing a cinder volume driver for my array and want to migrate volume from one volume type to another volume type for my array backends. so want to know how can i achieve this in cinder driver? Regards Nikesh __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Avishay Traeger* *Storage RD* Mobile: +972 54 447 1475 E-mail: avis...@stratoscale.com Web http://www.stratoscale.com/ | Blog http://www.stratoscale.com/blog/ | Twitter https://twitter.com/Stratoscale | Google+ https://plus.google.com/u/1/b/108421603458396133912/108421603458396133912/posts | Linkedin https://www.linkedin.com/company/stratoscale __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] auto-abandon changesets considered harmful (was Re: [stable][all] Revisiting the 6 month release cycle [metrics])
I have to agree with John. We have many more submitters than we have core folks, and our current scaling limits tend to be around core and reviews, not around submissions, so making life slightly more difficult for submitters in order to make it substantially easier for core is a reasonable trade. Not marking a review as abandoned if feedback hasn't been responded to in 2 week misleads reviewers and submitters, so I fully support the cinder abandonment rules - the 'restore change' button takes a moment to click. On 28 February 2015 at 03:02, John Griffith john.griffi...@gmail.com wrote: On Fri, Feb 27, 2015 at 5:40 PM, Stefano Maffulli stef...@openstack.org wrote: I'm not expressing myself cleary enough. I don't advocate for the removal of anything because I like pretty charts. I'm changing the subject to be even more clear. On Fri, 2015-02-27 at 13:26 -0800, James E. Blair wrote: I am asking you to please independently remove changes that you don't think should be considered from your metrics. I'm saying that the reports have indicators that seem to show struggle. In a previous message Kevin hinted that probably a reason for those bad looking numbers was due to a lot of reviews that appear to have been abandoned. This doesn't seem the case because some projects have a habit of 'purging'. I have never explicitly ordered developers to purge anything. If their decision to purge is due to the numbers they may have seen on the reports I'd like to know. That said, the problem that the reports highlight remains confirmed so far: contributors seem to be left in some cases hanging, for many many days, *after a comment* and they don't come back. I think abandoning changes so that the metrics look the way we want is a terrible experience for contributors. I agree, that should not be a motivator. Also, after chatting with you on IRC I tend to think that instead of abandoning the review we should highlight them and have humans act on them. Maybe build a dashboard of 'old stuff' to periodically sift through and see if there are things worth picking up again or to ping the owner or something else managed by humans. I happened to have found one of such review automatically closed that could have been fixed with a trivial edit in commit message instead: https://review.openstack.org/#/c/98735/ (that owner had a bunch of auto-abandoned patches https://review.openstack.org/#/q/owner:%22Mh+Raies+%253Craiesmh08% 2540gmail.com%253E%22,n,z https://review.openstack.org/#/q/owner:%22Mh+Raies+%253Craiesmh08%2540gmail.com%253E%22,n,z). I have made a note to reach out to him and get more anecdotes. Especially as it appears some projects, such as nova, are in a position where they are actually leaving -2 votes on changes which will not be lifted for 2 or 3 months. That means that if someone runs a script like Sean's, these changes will be abandoned, yet there is nothing that the submitter can do to progress the change in the mean time. Abandoning such a review is making an already bad experience for contributors even worse. this sounds like a different issue :( __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev For what it's worth, at one point the Cinder project setup an auto-abandon job that did purge items that had a negative mark either from a reviewer or from Jenkins and had not been updated in over two weeks. This had absolutely nothing to do with metrics or statistical analysis of the project. We simply had a hard time dealing with patches that the submitter didn't care about. If somebody takes the time to review a patch, then I don't think it's too much to ask that the submitter respond to questions or comments within a two week period. Note, the auto purge in our case only purged items that had no updates or activity at all. We were actually in a position where we had patches that were submitted, failed unit tests in the gate (valid failures that occurred 100% of the time) and had sat for an entire release without the submitter ever updating the patch. I don't think it's unreasonable at all to abandon these and remove them from the queue. I don't think this is a bad thing, I think it's worse to leave them as active when they're bit-rotted and the submitter doesn't even care about them any longer. The other thing is, those patches are still there, they can still be accessed and reinstated. There's a lot of knocks against core teams regarding time to review and keeping up with the work load.. that's fine, but at the same time if you submit something you should follow through on it and respond to comments or test failures in a timely manner. Also there should be some scaling factor here; if a
Re: [openstack-dev] [cinder][horizon]Proper error handling/propagation to UI
I thought that case should be caught well before it gets to the driver. Can you retry with the LVM driver please? On 27 February 2015 at 10:48, Eduard Matei eduard.ma...@cloudfounders.com wrote: Hi, We've been testing our cinder driver extensively and found a strange behavior in the UI: - when trying to delete a snapshot that has clones (created volume from snapshot) and error is raised in our driver which turns into error_deleting in cinder and the UI; further actions on that snapshot are impossible from the ui, the user has to go to CLI and do cinder snapshot-reset-state to be able to delete it (after having deleted the clones) - to help with that we implemented a check in the driver and now we raise exception.SnapshotIsBusy; now the snapshot remains available (as it should be) but no error bubble is shown in the UI (only the green one: Success. Scheduled deleting of...). So the user has to go to c-vol screen and check the cause of the error So question: how should we handle this so that a. The snapshot remains in state available b. An error bubble is shown in the UI stating the cause. Thanks, Eduard -- *Eduard Biceri Matei, Senior Software Developer* www.cloudfounders.com | eduard.ma...@cloudfounders.com *CloudFounders, The Private Cloud Software Company* Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee or an employee or agent responsible for delivering this message to the named addressee, you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this email in error we request you to notify us by reply e-mail and to delete all electronic files of the message. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. E-mail transmission cannot be guaranteed to be secure or error free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the content of this message, and shall have no liability for any loss or damage suffered by the user, which arise as a result of e-mail transmission. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] what code in cinder volume driver supports volume migration between two backends of same type but having different volume types? [cinder]
Migrate - move between backends of the same volume type Retype - move between types. Will migrate the volume for you if necessary On 1 March 2015 at 09:40, Avishay Traeger avis...@stratoscale.com wrote: Nikesh, The case you are trying is supposed to fail. You have a volume of type dothill_realstor1 which is defined to say this volume must be on backend DotHill_RealStor1. This is a requirement that you defined for that volume. Now you want to migrate it to realstor2, which is a violation of the requirement that you specified. To migrate it, you should change the volume type (retype), which changes the requirement. Thanks, Avishay On Sat, Feb 28, 2015 at 11:02 AM, Nikesh Kumar Mahalka nikeshmaha...@vedams.com wrote: I tried below link for volume migration on my driver and also similar efforts for LVM. Even whatever documents available in openstack for volume-migration,each one showing volume migration of a volume having volume type None I added host assisted volume migration function in my cinder driver. When i am trying volume migration on a volume without volume type,then my volume migration function is getting called and i am able to do volume migration. But when i am trying volume migration on a volume having volume type,then my volume migration function is not getting called. http://paste.openstack.org/show/183392/ http://paste.openstack.org/show/183405/ On Tue, Jan 20, 2015 at 12:31 AM, Nikesh Kumar Mahalka nikeshmaha...@vedams.com wrote: do cinder retype (v2) works for lvm? How to use cinder retype? I tried for volume migration from one volume-type LVM backend to another volume-type LVM backend.But its failed. How can i acheive this? Similarly i am writing a cinder volume driver for my array and want to migrate volume from one volume type to another volume type for my array backends. so want to know how can i achieve this in cinder driver? Regards Nikesh __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Avishay Traeger* *Storage RD* Mobile: +972 54 447 1475 E-mail: avis...@stratoscale.com Web http://www.stratoscale.com/ | Blog http://www.stratoscale.com/blog/ | Twitter https://twitter.com/Stratoscale | Google+ https://plus.google.com/u/1/b/108421603458396133912/108421603458396133912/posts | Linkedin https://www.linkedin.com/company/stratoscale __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] Adding vendor drivers in Ironic
Excerpts from Gary Kotton's message of 2015-03-01 02:32:37 -0800: Hi, I am just relaying pain-points that we encountered in neutron. As I have said below it makes the development process a lot quicker for people working on external drivers. I personally believe that it fragments the community and feel that the external drivers loose the community contributions and inputs. I think you're right that this does change the dynamic in the community. One way to lower the barrier is to go ahead and define the plugin API very strongly, but then delegate control of drivers in-tree to active maintainers, rather than in external repositories. If a driver falls below the line in terms of maintenance, then it can be deprecated. And if a maintainer feels strongly that they cannot include the driver with Ironic for whatever reason, the plugin API being strongly defined will allow them to do so. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] volume's current host in retype [cinder]
On Sun, Mar 1, 2015 at 12:53 PM, Nikesh Kumar Mahalka nikeshmaha...@vedams.com wrote: Hi, i was trying to understand below patch: https://review.openstack.org/#/c/44881/24 What volume's current host means in this patch? I want to understand it with some examples. Regards Nikesh ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openst...@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Please don't cross post against both general and dev lists. Also you and I have had this conversation multiple times in IRC, your best bet is to continue with these sorts of questions in #openstack-cinder. Not private message, but the Cinder channel, and if there are still things that aren't clear you should ask there for help with your driver development. Thanks, John __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
