[openstack-dev] [Magnum][Containers] Magnum Midcycle Agenda
Team, It is not too late to register for the our Midcycle Meetup in San Francisco for Monday 3/2 and Tuesday 3/3. Find the link to tickets on the Wiki page: https://wiki.openstack.org/wiki/Magnum/Midcycle I have published the revised Agenda Etherpad (subject to change): https://etherpad.openstack.org/p/magnum-midcycle-topics Asks: 1) For those of you wishing to attend remotely, please add your names and timezones to the REMOTES line for that session. We will have a webex conference set up to allow for remote participation. 2) Our discussions will have a leader, and a scribe for etherpad note taking. Please sign up to lead sessions you proposed by putting your name on the etherpad next to LEADER for that session. 3) We will be keeping notes for each session in the linked etherpads. Everyone is encouraged to participate in interactive note taking. Please volunteer to take scribe duty for at least one of the sessions. Pick the session that you are unlikely to do a lot of talking in. 4) If you are a remote attendee, and you would like us to move a session to a different time because of your timezone, or other reason, please contact me directly by email so I can work to accommodate you. 5) You may add additional topics to the numbered list at the bottom of the Agenda etherpad. We can fit topics into the Parking Lot timeslots. I look forward to seeing all of you in San Francisco (in person, or remotely) on Monday. Thanks, Adrian __ 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] [Sahara][HDP]Cluster staty in Configuring status forever
Hi Sahara, I'm a new bird here for both sahara HDP. I just installed a total fresh all-in-one Openstack environment by devstack, and want to build my first Hadoop cluster. Limited to my knowledge about Hadoop and HDP, I hope to build a cluster as small as I can. All things are build based on plugin HDP 2.0.6. 1. I created 2 node-group templates: a. Master NAMENODE ZOOKEEPER_SERVER AMBARI_SERVER HISTORYSERVER RESOURCEMANAGER b. slave NODEMANAGER 2. I create a cluster template which include the above 2 node groups. 3. I launched the cluster in Horizon, and started waiting... 4. The cluster stalled at status Configuring. Anyone know why this happened ?? Thanks. -chen I did a little check, as nova list showed: nova list +--+---+++-++ | ID | Name | Status | Task State | Power State | Networks | +--+---+++-++ | f2e27b00-858e-4c71-822d-abc1bd35b0d4 | kk-basic-master-001 | ACTIVE | - | Running | private=10.0.0.4, 192.169.14.3 | | e757756c-7d53-49e0-91b1-af7e67b85f03 | kk-smallest-slave-001 | ACTIVE | - | Running | private=10.0.0.5, 192.169.14.4 | +--+---+++-++ Instances were started successfully and network is working well too. The sahara log keeps printing: 2015-02-28 16:30:27.908 DEBUG sahara.utils.ssh_remote [-] [kk-basic-master-001] Retrieving HTTP session for 192.169.14.3:8080 from (pid=28144) _log_command /opt/stack/sahara/sahara/utils/ssh_remote.py:759 2015-02-28 16:30:27.909 DEBUG sahara.utils.ssh_remote [-] cached HTTP session for 192.169.14.3:8080 is requests.sessions.Session object at 0x7f3ed9aa9450 from (pid=28144) _get_http_client /opt/stack/sahara/sahara/utils/ssh_remote.py:200 2015-02-28 16:30:27.910 DEBUG urllib3.util.retry [-] Converted retries value: 0 - Retry(total=0, connect=None, read=None, redirect=0) from (pid=28144) from_int /usr/local/lib/python2.7/dist-packages/urllib3/util/retry.py:155 2015-02-28 16:30:27.911 INFO urllib3.connectionpool [-] Resetting dropped connection: proxy-socks.sc.intel.com 2015-02-28 16:30:28.216 DEBUG urllib3.connectionpool [-] GET http://192.169.14.3:8080/api/v1/hosts HTTP/1.1 503 784 from (pid=28144) _make_request /usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py:368 2015-02-28 16:30:28.219 INFO sahara.plugins.hdp.versions.version_2_0_6.versionhandler [-] Waiting to connect to ambari server ... 2015-02-28 16:30:32.277 DEBUG sahara.openstack.common.periodic_task [-] Running periodic task SaharaPeriodicTasks.terminate_unneeded_transient_clusters from (pid=28144) run_periodic_tasks /opt/stack/sahara/sahara/openstack/common/periodic_task.py:219 2015-02-28 16:30:32.277 DEBUG sahara.service.periodic [-] Terminating unneeded transient clusters from (pid=28144) terminate_unneeded_transient_clusters /opt/stack/sahara/sahara/service/periodic.py:131 2015-02-28 16:30:32.316 DEBUG sahara.openstack.common.loopingcall [-] Dynamic looping call bound method SaharaPeriodicTasks.run_periodic_tasks of sahara.service.periodic.SaharaPeriodicTasks object at 0x7f3edb415950 sleeping for 9.96 seconds from (pid=28144) _inner /opt/stack/sahara/sahara/openstack/common/loopingcall.py:132 2015-02-28 16:30:33.278 DEBUG sahara.utils.ssh_remote [-] [kk-basic-master-001] Retrieving HTTP session for 192.169.14.3:8080 from (pid=28144) _log_command /opt/stack/sahara/sahara/utils/ssh_remote.py:759 2015-02-28 16:30:33.279 DEBUG sahara.utils.ssh_remote [-] cached HTTP session for 192.169.14.3:8080 is requests.sessions.Session object at 0x7f3ed9aa9450 from (pid=28144) _get_http_client /opt/stack/sahara/sahara/utils/ssh_remote.py:200 2015-02-28 16:30:33.280 DEBUG urllib3.util.retry [-] Converted retries value: 0 - Retry(total=0, connect=None, read=None, redirect=0) from (pid=28144) from_int /usr/local/lib/python2.7/dist-packages/urllib3/util/retry.py:155 2015-02-28 16:30:33.281 INFO urllib3.connectionpool [-] Resetting dropped connection: proxy-socks.sc.intel.com 2015-02-28 16:30:33.573 DEBUG urllib3.connectionpool [-] GET http://192.169.14.3:8080/api/v1/hosts HTTP/1.1 503 784 from (pid=28144) _make_request /usr/local/lib/python2.7/dist-packages/urllib3/connectionpool.py:368 2015-02-28 16:30:33.574 INFO sahara.plugins.hdp.versions.version_2_0_6.versionhandler [-] Waiting to connect to ambari server ... 2015-02-28 16:30:38.634 DEBUG sahara.utils.ssh_remote [-] [kk-basic-master-001] Retrieving HTTP session for 192.169.14.3:8080 from (pid=28144) _log_command /opt/stack/sahara/sahara/utils/ssh_remote.py:759
Re: [openstack-dev] [Magnum] Mid-Cycle Meetup Planning
The full agenda is linked from: https:// wiki.openstack.org/wiki/Magnum/Mid-Cycle See my other email for my 5 asks of our participants. Adrian Original message From: Weidong Shao Date:02/27/2015 10:33 PM (GMT-08:00) To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Magnum] Mid-Cycle Meetup Planning Could you post the detailed agenda for both days? Thanks! On Mon, Jan 26, 2015 at 3:54 PM Adrian Otto adrian.o...@rackspace.commailto:adrian.o...@rackspace.com wrote: Team, Thanks for participating in the poll. Due to considerable scheduling conflicts, I am expanding the poll to include the following Monday 2015-03-02+Tuesday 2015-03-03. Hopefully these alternate dates can get more of us together on the same days. Please take a moment to respond to the poll a second time to indicate your availability on the newly proposed dates: http://doodle.com/ddgsptuex5u3394m Thanks, Adrian On Jan 8, 2015, at 2:24 PM, Adrian Otto adrian.o...@rackspace.commailto:adrian.o...@rackspace.com wrote: Team, If you have been watching the Magnum project you know that things have really taken off recently. At Paris we did not contemplate a Mid-Cycle meet-up but now that we have come this far so quickly, and have such a broad base of participation now, it makes sense to ask if you would like to attend a face-to-face mid-cycle meetup. I propose the following for your consideration: - Two full days to allow for discussion of Magnum architecture, and implementation of our use cases. - Located in San Francisco. - Open to using Los Angeles or another west coast city to drive down travel expenses, if that is a concern that may materially impact participation. - Dates: February 23+24 or 25+26 If you think you can attend (with 80+% certainty) please indicate your availability on the proposed dates using this poll: http://doodle.com/ddgsptuex5u3394m Please also add a comment on the Doodle Poll indicating what Country/US City you will be traveling FROM in order to attend. I will tabulate the responses, and follow up to this thread. Feel free to respond to this thread to discuss your thoughts about if we should meet, or if there are other locations or times that we should consider. Thanks, Adrian PS: I do recognize that some of our contributors reside in countries that require Visas to travel to the US, and those take a long time to acquire. The reverse is also true. For those of you who can not attend in person, we will explore options for remote participation using teleconferencing technology, IRC, Etherpad, etc for limited portions of the agenda. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org 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:unsubscribehttp://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] Need help in configuring keystone
Hi Marco, did you get a chance to look at the logs, Regards,Akshik From: aks...@outlook.com To: openstack-dev@lists.openstack.org Date: Fri, 27 Feb 2015 22:50:47 +0530 Subject: Re: [openstack-dev] Need help in configuring keystone Hi Marco, Thanks for responding, Ive cleared the log file and have restarted the shibd service. the metadata file got created, i've attached the log file and metadata file as well. Regards,Akshik Date: Fri, 27 Feb 2015 15:12:39 +0100 From: marco.farge...@ct.infn.it To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Need help in configuring keystone Hi Akshik, the metadata error is in your SP, if the error was on testshib you should not be redirected back after the login. Maybe there is a configuration problem with shibboleth. Try to restart the service and look at shibboleth logs. Check also the metadata of testshib are downloaded correctly because from the error it seems you have not the metadata of testshib. Cheers, Marco On Fri, Feb 27, 2015 at 06:39:30PM +0530, Akshik DBK wrote: Hi Marek , I've registered with testshib, this is my keystone-apache-error.log log i get [error] [client 121.243.33.212] No MetadataProvider available., referer: https://idp.testshib.org/idp/profile/SAML2/Redirect/SSO From: aks...@outlook.com To: openstack-dev@lists.openstack.org Date: Fri, 27 Feb 2015 15:56:57 +0530 Subject: [openstack-dev] Need help in configuring keystone Hi I'm new to SAML, trying to integrate keystone with SAML, Im using Ubuntu 12.04 with Icehouse,im following http://docs.openstack.org/developer/k...when im trying to configure keystone with two idp,when i access https://MYSERVER:5000/v3/OS-FEDERATIO...it gets redirected to testshib.org , it prompts for username and password when the same is given im gettingshibsp::ConfigurationException at ( https://MYSERVER:5000/Shibboleth.sso/... ) No MetadataProvider available.here is my shibboleth2.xml contentSPConfig xmlns=urn:mace:shibboleth:2.0:native:sp:config xmlns:conf=urn:mace:shibboleth:2.0:native:sp:config xmlns:saml=urn:oasis:names:tc:SAML:2.0:assertion xmlns:samlp=urn:oasis:names:tc:SAML:2.0:protocol xmlns:md=urn:oasis:names:tc:SAML:2.0:metadata clockSkew=180 ApplicationDefaults entityID=https://MYSERVER:5000/Shibboleth; Sessions lifetime=28800 timeout=3600 checkAddress=false relayState=ss:mem handlerSSL=false SSO entityID=https://idp.testshib.org/idp/shibboleth; ECP=true SAML2 SAML1 /SSO LogoutSAML2 Local/Logout Handler type=MetadataGenerator Location=/Metadata signing=false/ Handler type=Status Location=/Status / Handler type=Session Location=/Session showAttributeValues=false/ Handler type=DiscoveryFeed Location=/DiscoFeed/ /Sessions Errors supportContact=root@localhost logoLocation=/shibboleth-sp/logo.jpg styleSheet=/shibboleth-sp/main.css/ AttributeExtractor type=XML validate=true path=attribute-map.xml/ AttributeResolver type=Query subjectMatch=true/ AttributeFilter type=XML validate=true path=attribute-policy.xml/ CredentialResolver type=File key=sp-key.pem certificate=sp-cert.pem/ ApplicationOverride id=idp_1 entityID=https://MYSERVER:5000/Shibboleth; Sessions lifetime=28800 timeout=3600 checkAddress=false relayState=ss:mem handlerSSL=false SSO entityID=https://portal4.mss.internalidp.com/idp/shibboleth; ECP=true SAML2 SAML1 /SSO LogoutSAML2 Local/Logout /Sessions MetadataProvider type=XML uri=https://portal4.mss.internalidp.com/idp/shibboleth; backingFilePath=/tmp/tata.xml reloadInterval=18 / /ApplicationOverride ApplicationOverride id=idp_2 entityID=https://MYSERVER:5000/Shibboleth; Sessions lifetime=28800 timeout=3600 checkAddress=false relayState=ss:mem handlerSSL=false SSO entityID=https://idp.testshib.org/idp/shibboleth; ECP=true SAML2 SAML1 /SSO LogoutSAML2 Local/Logout /Sessions MetadataProvider type=XML uri=https://idp.testshib.org/idp/shibboleth; backingFilePath=/tmp/testshib.xml reloadInterval=18/ /ApplicationOverride /ApplicationDefaults SecurityPolicyProvider type=XML validate=true path=security-policy.xml/ ProtocolProvider type=XML validate=true reloadChanges=false path=protocols.xml/ /SPConfighere is my wsgi-keystoneWSGIScriptAlias /keystone/main /var/www/cgi-bin/keystone/main WSGIScriptAlias /keystone/admin /var/www/cgi-bin/keystone/admin Location /keystone # NSSRequireSSL SSLRequireSSL Authtype none /Location
Re: [openstack-dev] what code in cinder volume driver supports volume migration between two backends of same type but having different volume types? [cinder]
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
Re: [openstack-dev] [cinder] Ask for review for cinder driver patch
On 02/27/2015 10:02 PM, liuxinguo wrote: Hi Mike, I have fixed the patch as your comments and have committed it at https://review.openstack.org/#/c/152116/. Would you please have a review at it, thanks! Best regards, Liu __ 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 The mailing list is not the place to ask for reviews on patches. If you want to discuss the status of a patch the best place is to join irc, in this case #openstack-cinder, and discuss the patch and its status in there. Thank you, Anita. __ 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
On 02/28/2015 01:28 AM, Ramakrishnan G wrote: 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://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/operations.py ). 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://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/ris.py) for Ironic folks, they will hardly take a look at it. And regarding testing, it's not tested in the gate unless we have a 3rd party CI for it. [We (iLO drivers) also don't have 3rd party CI right now, but we are working on it.] *2) Everything gets packaged into distributions automatically:* Now the hardware-specific code that we add in Ironic under drivers/modules/vendor/ will get packaged into distributions, but this code in turn will have dependencies which needs to be installed manually by the operator (I assume vendor specific dependencies are not considered by Linux distributions while packaging Openstack Ironic). Anyone installing Ironic and wanting to manage my company's servers will again need to install these dependencies manually. Why not install the wrapper if there is one too. I assume we only get these advantages by moving all of hardware-specific code to a wrapper module in stackforge and just exposing some APIs for Ironic to use: * Ironic code would be much cleaner and easier to maintain * Any changes related to your hardware - support for newer hardware, bug fixes in particular models of hardware, would be very easy. You don't need to change Ironic code for that. You could just fix the bug in your module, release a new version and ask your users to install a newer version of the module. * python-fooclient could be used outside Ironic to easily manage foo servers. * Openstack CI for free if you are in stackforge - unit tests, flake tests, doc generation, merge, pypi release everything handled automatically. I don't see any disadvantages. Now regarding the time taken to do this, if you have all the code ready now in Ironic (which assume you will already have), perhaps it will take a day to do this - half a day for putting into a separate module in python/github and half a day for stackforge. The request to add stackforge should get approved in the same day (if everything is all-right). You may not realize you do a disservice to those reading this post and those reviewing future patches if you set unreasonable expectations. Telling others that they can expect a patch merged in the same day is not reasonable, even if that has been your experience. While we do our best to keep current, we all are very busy and requests for repos are increasing. If folks want a repo they can submit a patch to create one, here is a good guide: http://docs.openstack.org/infra/manual/creators.html and it will be reviewed along with all other patches to project-config. Thank you, Anita. Let me know all of your thoughts on this. If we agree, I feel we should have some documentation on it in our Ironic docs directory. Thanks for reading :) Regards, Ramesh
Re: [openstack-dev] [nova] how safe is it to change NoAuthMiddlewareBase?
On 02/26/2015 04:27 AM, Sean Dague wrote: In trying to move the flavor manage negative tests out of Tempest and into the Nova functional tree, I ran into one set of tests which are permissions checking. Basically that a regular user isn't allowed to do certain things. In (nearly) all our tests we use auth_strategy=noauth which takes you to NoAuthMiddlewareBase instead of to keystone. That path makes you an admin regardless of what credentials you send in - https://github.com/openstack/nova/blob/master/nova/api/openstack/auth.py#L56-L59 What I'd like to do is to change this so that if you specify user_id='admin' then is_admin is set true, and it's not true otherwise. That has a bunch of test fall out, because up until this point most of the test users are things like 'fake', which would regress to non admin. About 25% of the api samples tests fail in such a change, so they would need to be fixed. Taking a step back... what exactly is the purpose of the API samples functional tests? If the purpose of these tests has anything to do with validating some policy thing, then I suppose it's worth changing the auth middleware to support non-adminness. But, I don't think the API samples test purpose has anything to do with that (I think the purpose of the API samples tests is fuzzy, at best, actually). So, I'd just leave them as-is and not change anything at all. Best, -jay __ 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
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.org Date: Saturday, February 28, 2015 at 8:28 AM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org 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://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/operations.pyhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackforge_proliantutils_blob_master_proliantutils_ilo_operations.pyd=AwMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=m5_FxZnmz3cyIvavSV 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://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/ris.pyhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackforge_proliantutils_blob_master_proliantutils_ilo_ris.pyd=AwMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=m5_FxZnmz3cyIvavSVDImH6xLR79L-svbcYKkjdcnb8s=vYNQ8MopljQOqje3T_aIhtw0oZPK4tFHGnlcbBH6wace=) for Ironic folks, they will hardly take a look at it. And regarding testing, it's not tested in the gate unless we have a 3rd party CI for it. [We (iLO drivers) also don't have 3rd party CI right now, but we are working on it.] 2) Everything gets packaged into distributions automatically: Now the hardware-specific code that we add in Ironic under drivers/modules/vendor/ will get packaged into distributions, but this code in turn will have dependencies which needs to be installed manually by the
[openstack-dev] Heat: autoscaling across availability zones
From the heat template reference doc, it seems that auto-scaling across AZs is not supported. Is there any blueprint or plan in adding this support? Thanks, Wei __ 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
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.org Date: Saturday, February 28, 2015 at 8:28 AM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org 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://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/operations.pyhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackforge_proliantutils_blob_master_proliantutils_ilo_operations.pyd=AwMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=m5_FxZnmz3cyIvavSVDImH6xLR79L-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://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/ris.pyhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stackforge_proliantutils_blob_master_proliantutils_ilo_ris.pyd=AwMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=m5_FxZnmz3cyIvavSVDImH6xLR79L-svbcYKkjdcnb8s=vYNQ8MopljQOqje3T_aIhtw0oZPK4tFHGnlcbBH6wace=) for Ironic folks, they will hardly take a look at it. And regarding testing, it's not tested in the gate unless we have a 3rd party CI for it. [We (iLO drivers) also don't have 3rd party CI right now, but we are working on it.] 2) Everything gets packaged into distributions automatically: Now the hardware-specific code that we add in Ironic under drivers/modules/vendor/ will get packaged into distributions, but this code in turn will have dependencies which needs to be installed manually by the operator (I assume vendor specific dependencies are not considered by Linux distributions while packaging Openstack Ironic). Anyone installing Ironic and wanting to manage my company's servers will again need to install these dependencies manually. Why not install the wrapper if there is one too. I assume we only get these advantages by moving all of hardware-specific code to a wrapper module in stackforge and just exposing some APIs for Ironic to use: * Ironic code would be much cleaner and easier to maintain * Any changes related to your hardware - support for newer hardware, bug fixes in particular models of hardware, would be very easy. You don't need to change Ironic code for that. You could just fix the bug in your module, release a new version
Re: [openstack-dev] Heat: autoscaling across availability zones
From: Weidong Shao weidongs...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 02/28/2015 02:12 PM Subject: [openstack-dev] Heat: autoscaling across availability zones From the heat template reference doc, it seems that auto-scaling across AZs is not supported. Is there any blueprint or plan in adding this support? Yes. Here are some ways you can find that work: https://blueprints.launchpad.net/openstack/?searchtext=availabilityzone https://review.openstack.org/#/q/message:availability+message:zone,n,z includes some relevant answers; I have not yet figured out how to narrow the query to match only items in the heat and heat-specs projects. Subscribe to notifications from Gerrit about activity in the Heat project, watch the email subject lines as they whizz by. Regards, Mike__ 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
You may not realize you do a disservice to those reading this post and those reviewing future patches if you set unreasonable expectations. Telling others that they can expect a patch merged in the same day is not reasonable, even if that has been your experience. While we do our best to keep current, we all are very busy and requests for repos are increasing. If folks want a repo they can submit a patch to create one, here is a good guide: http://docs.openstack.org/infra/manual/creators.html and it will be reviewed along with all other patches to project-config. Anita, Thanks for correcting me. Yeah, I just quoted *my experience with openstack-infra *blindly. Sorry for that. Rather I also wanted to point out to our folks, things in infra are so automated that putting an openstack-related module into stackforge has been become fully automatic and easy *(easy for the requestor, of course keeping in mind that the request has to be correct and get's reviewed and approved by infra guys)*. Kudos to you guys :-) Regards, Ramesh On Sun, Mar 1, 2015 at 12:49 AM, Anita Kuno ante...@anteaya.info wrote: On 02/28/2015 01:28 AM, Ramakrishnan G wrote: 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://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/operations.py ). 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://github.com/stackforge/proliantutils/blob/master/proliantutils/ilo/ris.py ) for Ironic folks, they will hardly take a look at it. And regarding testing, it's not tested in the gate unless we have a 3rd party CI for it. [We (iLO drivers) also don't have 3rd party CI right now, but we are working on it.] *2) Everything gets packaged into distributions automatically:* Now the hardware-specific code that we add in Ironic under drivers/modules/vendor/ will get packaged into distributions, but this code in turn will have dependencies which needs to be installed manually by the operator (I assume vendor specific dependencies are not considered by Linux distributions while packaging Openstack Ironic). Anyone installing Ironic and wanting to manage my company's servers will again need to install these dependencies manually. Why not install the wrapper if there is one too. I assume we only get these advantages by moving all of hardware-specific code to a wrapper module in stackforge and just exposing some APIs for Ironic to use: * Ironic code would be much cleaner and easier to maintain * Any changes related to your hardware - support for newer hardware, bug fixes in particular models of hardware, would be very easy. You don't need to change Ironic code for that. You could just fix the bug in your module, release a new version and ask your users to install a newer version of the module. * python-fooclient could be used outside Ironic to easily manage foo servers. * Openstack CI for free if you are in stackforge - unit tests, flake tests, doc generation, merge, pypi release
Re: [openstack-dev] what code in cinder volume driver supports volume migration between two backends of same type but having different volume types? [cinder]
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
