Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need help setting up CI
Hi Eduard,
Can you put the logs or details for below comment:
it seems that sometimes Zuul gets stuck (sometimes in Looking for lost
builds, sometimes doing nothing) and it misses notifications.
I guess, we too have been facing the same issue with Zuul.
Regards,
Amit
*CloudByte Inc.* http://www.cloudbyte.com/
On Thu, Jan 15, 2015 at 6:29 PM, Eduard Matei
eduard.ma...@cloudfounders.com wrote:
Hi,
Just so i don't start another thread: it seems that sometimes Zuul gets
stuck (sometimes in Looking for lost builds, sometimes doing nothing) and
it misses notifications.
I added a Jenkins timer job to restart it every 30 minutes. Is there a fix
for this or something to change in config?
Thanks,
Eduard
On Thu, Jan 15, 2015 at 2:56 PM, Eduard Matei
eduard.ma...@cloudfounders.com wrote:
Hi Ramy,
The issue with disconnect/abort no longer happens, so i guess it was some
issues with networking.
Regarding the ssh keys i finally used Jenkins Configuration Provider
Plugin to inject ssh keys as a pre-build step, then i added a manual
execution step to scp the logs to the server, so now everything appears to
be working.
Now for the REAL tests:
looking at
https://github.com/rasselin/os-ext-testing-data/blob/master/etc/jenkins_jobs/config/dsvm-cinder-driver.yaml.sample#L7
it seems i need to put the code to install my third party libs in the
pre_test_hook which appears in devstack-vm-gate-wrap.sh to be executing
BEFORE installing devstack. The problem is we need our third party libs
to be installed (actually configured) AFTER installing devstack, since they
install on top of devstack and do some configuration on devstack.
How could i integrate my code into devstack-vm-gate-wrap.sh so that my
libs are installed after devstack but before running tempest.
Also, as a side question, do i need to run all the test (since they
already run in dsvm-tempest-full) or can i run only our internal
functionality tests? (in this case i don't need devstack-vm-gate-wrap.sh
and i can run custom code directly from jenkins job).
Thanks,
Eduard
On Wed, Jan 14, 2015 at 6:49 PM, Asselin, Ramy ramy.asse...@hp.com
wrote:
Double check your ssh public/private key, authorized keys
configuration in the slave log server.
They should all match up. No passwords should be requested.
Try doing a manual scp as Jenkins user from the slave to the log server
(as Jenkins user there too).
Regarding manually setting up the publisher, I don’t know. Jenkins Job
Builder configuration I referenced below should work correctly.
Ramy
*From:* Eduard Matei [mailto:eduard.ma...@cloudfounders.com]
*Sent:* Wednesday, January 14, 2015 6:56 AM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [OpenStack-Infra] [ThirdPartyCI] Need
help setting up CI
Hi Ramy,
I think i managed to setup SCP plugin and updated zuul.conf but it only
uploads the console.html not the logs
I have an SCP site pointing to the apache server and the root location
is /srv/static, and in the dsvm job manually added a post-build step,
Publish Artifacts to SCP Repository, with source: logs/** and destination
logs/${LOG_PATH} and also checked Copy Console Log.
The destination path is created, but it only contains console.html.
I tried to manually scp the directory, but the jenkins user in the
devstack_slave asks for a password when trying to ssh to apache server.
Thanks,
Eduard
On Wed, Jan 14, 2015 at 10:40 AM, Eduard Matei
eduard.ma...@cloudfounders.com wrote:
Thanks Ramy, i'll try to set it up manually.
Meanwhile i found another problem: jobs are failing because of error or
are being aborted.
FATAL: java.io.IOException: Unexpected termination of the channel
hudson.remoting.RequestAbortedException
http://stacktrace.jenkins-ci.org/search?query=hudson.remoting.RequestAbortedException:
java.io.IOException: Unexpected termination of the channel
Is this related to another warning i got:
WARNING: devstack run took 15 minutes, this is a very slow node.
Is there a timeout for how long a job is allowed to run?
Most jobs take between 40 and 60 minutes, some are able to run
successfully, some are aborted or get this error.
Hardware is Xeon E3-1220 Quad core 3.10 Ghz, 32 GB RAM and 3x 1TB sata HDD.
Devstack slaves are configured as m1.large (4 vCPUs, 8 GB vRAM and 80 GB
vHDD).
Thanks,
Eduard
On Tue, Jan 13, 2015 at 5:34 PM, Asselin, Ramy ramy.asse...@hp.com
wrote:
Hi Eduard,
Apache logs server address is set here (should probably add some
comment/doc for that)
https://github.com/rasselin/os-ext-testing-data/blob/master/vars.sh.sample#L10
Jenkins will get configured here:
https://github.com/rasselin/os-ext-testing/blob/master/puppet/modules/os_ext_testing/templates/jenkins/be.certipost.hudson.plugin.SCPRepositoryPublisher.xml.erb
Note that you need to restart Jenkins for those changes to take
Re: [openstack-dev] 答复: [devstack] Opensatck installation issue.
Is this related to the version of Ubuntu being used ? Its 12.04 as per the email. Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Mon, Jan 12, 2015 at 3:55 PM, Abhishek Shrivastava abhis...@cloudbyte.com wrote: I tried that also but still the error is same. On Mon, Jan 12, 2015 at 3:32 PM, Pasquale Porreca pasquale.porr...@dektech.com.au wrote: Since it seems a permission error, this may help: http://docs.openstack.org/developer/devstack/guides/single-machine.html#installation-shake-and-bake NB: in my environment I had to edit the file sudoers with a text editor (echoing the string didn't work). On 01/12/15 09:33, Abhishek Shrivastava wrote: Hi all, I am still getting the same error while installing the Openstack through devstack, If someone know the solution please reply. On Fri, Jan 9, 2015 at 1:53 PM, Abhishek Shrivastava abhis...@cloudbyte.com wrote: Hi Liuxinguo, Thanks for the suggestion, I'll try and make it work. On Fri, Jan 9, 2015 at 1:24 PM, liuxinguo liuxin...@huawei.com wrote: Hi Abhishek, For the error in the first line: “mkdir: cannot create directory `/logs': Permission denied” and the error at the end: “ln: failed to create symbolic link `/logs/screen/screen-key.log': No such file or directory” The stack user does not have the permission on “/” so it can not create directory `/logs'. Please check the permission. liu *发件人:* Abhishek Shrivastava [mailto:abhis...@cloudbyte.com] *发 送时间:* 2015年1月9日 15:26 *收件人:* OpenStack Development Mailing List (not for usage questions) *主题:* [openstack-dev] [devstack] Opensatck installation issue. Hi, I'm trying to install *Openstack *through* devstack master* on my *Ubuntu* *12.04 VM*, but it is failing and generating the following error. If anyone can help me resolving this issue please do reply. -- *Thanks Regards,* *Abhishek* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *Thanks Regards, * *Abhishek* -- *Thanks Regards, * *Abhishek* __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Pasquale Porreca DEK Technologies Via dei Castelli Romani, 22 00040 Pomezia (Roma) Mobile +39 3394823805 Skype paskporr __ 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 -- *Thanks Regards,* *Abhishek* __ 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] Problem installing devstack
Can you check the /opt/stack/requirements folder check if thats updated (git status, git log) after doing unstack stack. One of the *-requirements.txt has the entry which makes all the projects to fail. We had removed the /opt/stack/requirements project then did a unstack stack. Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Tue, Jan 6, 2015 at 10:40 AM, Abhishek Shrivastava abhis...@cloudbyte.com wrote: Hi Rajdeep, Can you tell me the exact configuration (i.e;OS) you are using for installing devstack. On Tue, Jan 6, 2015 at 10:16 AM, Rajdeep Dua rajdeep@gmail.com wrote: Thanks for the response, in my case i am still getting the same error.. On Tue, Jan 6, 2015 at 9:28 AM, Ken'ichi Ohmichi ken1ohmi...@gmail.com wrote: 2015-01-06 12:40 GMT+09:00 Rajdeep Dua rajdeep@gmail.com: Getting this error while running stack.sh in devstack Could not find a version that satisfies the requirement SQLAlchemy=0.8.99,=0.9.99,=0.8.4,=0.9.7 (from keystone==2014.2.dev114) (from versions: 0.4.2p3, 0.4.7p1, 0.5.4p1, 0.5.4p2, 0.1.0, 0.1.1, 0.1.2, 0.1.3, 0.1.4, 0.1.5, 0.1.6, 0.1.7, 0.2.0, 0.2.1, 0.2.2, 0.2.3, 0.2.4, 0.2.5, 0.2.6, 0.2.7, 0.2.8, 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.3.7, 0.3.8, 0.3.9, 0.3.10, 0.3.11, 0.4.0b1, 0.4.0b2, 0.4.0b3, 0.4.0b4, 0.4.0b5, 0.4.0b6, 0.4.0, 0.4.1, 0.4.2a0, 0.4.2b0, 0.4.2, 0.4.3, 0.4.4, 0.4.5, 0.4.6, 0.4.7, 0.4.8, 0.5.0b1, 0.5.0b2, 0.5.0b3, 0.5.0rc1, 0.5.0rc2, 0.5.0rc3, 0.5.0rc4, 0.5.0, 0.5.1, 0.5.2, 0.5.3, 0.5.4, 0.5.5, 0.5.6, 0.5.7, 0.5.8, 0.6b1, 0.6b2, 0.6b3, 0.6.0, 0.6.1, 0.6.2, 0.6.3, 0.6.4, 0.6.5, 0.6.6, 0.6.7, 0.6.8, 0.6.9, 0.7.0, 0.7.1, 0.7.2, 0.7.3, 0.7.4, 0.7.5, 0.7.6, 0.7.7, 0.7.8, 0.7.9, 0.7.10, 0.8.0b2, 0.8.0, 0.8.1, 0.8.2, 0.8.3, 0.8.4, 0.8.5, 0.8.6, 0.8.7, 0.9.0, 0.9.1, 0.9.2, 0.9.3, 0.9.4, 0.9.5, 0.9.6, 0.9.7, 0.9.8) No distributions matching the version for SQLAlchemy=0.8.99,=0.9.99,=0.8.4,=0.9.7 (from keystone==2014.2.dev114) I saw a couple of bugs filed and patches going in. Please clarify if this is fixed and how to get the latest changes in. I faced the similar problem, and I could avoid it by removing /usr/local/lib/python2.7/dist-packages directory and ./stack.sh again. Hope that helps, Ken Ohmichi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks Regards, Abhishek ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] [driver] DB operations
Thanks Mike for getting me these useful reviews design discussions. So as it stands now, I am trying '*provider_id*' to map OpenStack/Cinder with the driver's backend storage. I got some useful review comments from @xing-yang to try out '*provider_id'* feature enabled by below commit: https://review.openstack.org/#/c/143205/ Do let me know if '*provider_id'* approach seems reasonable ? Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Thu, Dec 25, 2014 at 1:46 AM, Mike Perez thin...@gmail.com wrote: On 06:05 Sat 20 Dec , Duncan Thomas wrote: No, I mean that if drivers are going to access database, then they should do it via a defined interface that limits what they can do to a sane set of operations. I'd still prefer that they didn't need extra access beyond the model update, but I don't know if that is possible. Duncan Thomas On Dec 19, 2014 6:43 PM, Amit Das amit@cloudbyte.com wrote: Thanks Duncan. Do you mean hepler methods in the specific driver class? On 19 Dec 2014 14:51, Duncan Thomas duncan.tho...@gmail.com wrote: So our general advice has historical been 'drivers should not be accessing the db directly'. I haven't had chance to look at your driver code yet, I've been on vacation, but my suggestion is that if you absolutely must store something in the admin metadata rather than somewhere that is covered by the model update (generally provider location and provider auth) then writing some helper methods that wrap the context bump and db call would be better than accessing it directly from the driver. Duncan Thomas On Dec 18, 2014 11:41 PM, Amit Das amit@cloudbyte.com wrote: I've expressed in past reviews that we should have an interface that limits drivers access to the database [1], but received quite a bit of push back in Cinder. I recommend we stick to what has been decided, otherwise, Amit you should spend some time on reading the history of this issue [2] from previous meetings and start a rediscussion on it in the next meeting [3]. Not discouraging it, but this has been something brought up at least a couple of times now and it ends up with the same answer from the community. [1] - https://review.openstack.org/#/c/107693/14 [2] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-15-16.00.log.html#l-186 [3] - https://wiki.openstack.org/wiki/CinderMeetings -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] [driver] DB operations
Got it Duncan. I will re-check if I can arrive at any solution without accessing the database. Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Sat, Dec 20, 2014 at 7:35 PM, Duncan Thomas duncan.tho...@gmail.com wrote: No, I mean that if drivers are going to access database, then they should do it via a defined interface that limits what they can do to a sane set of operations. I'd still prefer that they didn't need extra access beyond the model update, but I don't know if that is possible. Duncan Thomas On Dec 19, 2014 6:43 PM, Amit Das amit@cloudbyte.com wrote: Thanks Duncan. Do you mean hepler methods in the specific driver class? On 19 Dec 2014 14:51, Duncan Thomas duncan.tho...@gmail.com wrote: So our general advice has historical been 'drivers should not be accessing the db directly'. I haven't had chance to look at your driver code yet, I've been on vacation, but my suggestion is that if you absolutely must store something in the admin metadata rather than somewhere that is covered by the model update (generally provider location and provider auth) then writing some helper methods that wrap the context bump and db call would be better than accessing it directly from the driver. Duncan Thomas On Dec 18, 2014 11:41 PM, Amit Das amit@cloudbyte.com wrote: Hi Stackers, I have been developing a Cinder driver for CloudByte storage and have come across some scenarios where the driver needs to do create, read update operations on cinder database (volume_admin_metadata table). This is required to establish a mapping between OpenStack IDs with the backend storage IDs. Now, I have got some review comments w.r.t the usage of DB related operations esp. w.r.t raising the context to admin. In short, it has been advised not to use *context.get_admin_context()* . https://review.openstack.org/#/c/102511/15/cinder/volume/drivers/cloudbyte/cloudbyte.py However, i get errors trying to use the default context as shown below: *2014-12-19 12:18:17.880 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/cinder/cinder/db/sqlalchemy/api.py, line 103, in is_admin_context* *2014-12-19 12:18:17.880 TRACE oslo.messaging.rpc.dispatcher return context.is_admin* *2014-12-19 12:18:17.880 TRACE oslo.messaging.rpc.dispatcher AttributeError: 'module' object has no attribute 'is_admin'* So what is the proper way to run these DB operations from within a driver ? Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] [driver] DB operations
Thanks Duncan. Do you mean hepler methods in the specific driver class? On 19 Dec 2014 14:51, Duncan Thomas duncan.tho...@gmail.com wrote: So our general advice has historical been 'drivers should not be accessing the db directly'. I haven't had chance to look at your driver code yet, I've been on vacation, but my suggestion is that if you absolutely must store something in the admin metadata rather than somewhere that is covered by the model update (generally provider location and provider auth) then writing some helper methods that wrap the context bump and db call would be better than accessing it directly from the driver. Duncan Thomas On Dec 18, 2014 11:41 PM, Amit Das amit@cloudbyte.com wrote: Hi Stackers, I have been developing a Cinder driver for CloudByte storage and have come across some scenarios where the driver needs to do create, read update operations on cinder database (volume_admin_metadata table). This is required to establish a mapping between OpenStack IDs with the backend storage IDs. Now, I have got some review comments w.r.t the usage of DB related operations esp. w.r.t raising the context to admin. In short, it has been advised not to use *context.get_admin_context()*. https://review.openstack.org/#/c/102511/15/cinder/volume/drivers/cloudbyte/cloudbyte.py However, i get errors trying to use the default context as shown below: *2014-12-19 12:18:17.880 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/cinder/cinder/db/sqlalchemy/api.py, line 103, in is_admin_context* *2014-12-19 12:18:17.880 TRACE oslo.messaging.rpc.dispatcher return context.is_admin* *2014-12-19 12:18:17.880 TRACE oslo.messaging.rpc.dispatcher AttributeError: 'module' object has no attribute 'is_admin'* So what is the proper way to run these DB operations from within a driver ? Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [cinder] [driver] DB operations
Hi Stackers, I have been developing a Cinder driver for CloudByte storage and have come across some scenarios where the driver needs to do create, read update operations on cinder database (volume_admin_metadata table). This is required to establish a mapping between OpenStack IDs with the backend storage IDs. Now, I have got some review comments w.r.t the usage of DB related operations esp. w.r.t raising the context to admin. In short, it has been advised not to use *context.get_admin_context()*. https://review.openstack.org/#/c/102511/15/cinder/volume/drivers/cloudbyte/cloudbyte.py However, i get errors trying to use the default context as shown below: *2014-12-19 12:18:17.880 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/cinder/cinder/db/sqlalchemy/api.py, line 103, in is_admin_context* *2014-12-19 12:18:17.880 TRACE oslo.messaging.rpc.dispatcher return context.is_admin* *2014-12-19 12:18:17.880 TRACE oslo.messaging.rpc.dispatcher AttributeError: 'module' object has no attribute 'is_admin'* So what is the proper way to run these DB operations from within a driver ? Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] #PERSONAL# : Git checkout command for Blueprints submission
Hi, It is git checkout -b bp/bp_name Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Wed, Dec 17, 2014 at 10:23 AM, Swati Shukla1 swati.shuk...@tcs.com wrote: Hi All, Generally, for bug submissions, we use git checkout -b bug/bug_number What is the similar 'git checkout' command for blueprints submission? Swati Shukla Tata Consultancy Services Mailto: swati.shuk...@tcs.com Website: http://www.tcs.com Experience certainty. IT Services Business Solutions Consulting =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] [UX] Curvature interactive virtual network design
+1 after looking at the videos. Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Tue, Dec 16, 2014 at 11:43 PM, Liz Blanchard lsure...@redhat.com wrote: On Nov 7, 2014, at 11:16 AM, John Davidge (jodavidg) jodav...@cisco.com wrote: As discussed in the Horizon contributor meet up, here at Cisco we’re interested in upstreaming our work on the Curvature dashboard into Horizon. We think that it can solve a lot of issues around guidance for new users and generally improving the experience of interacting with Neutron. Possibly an alternative persona for novice users? For reference, see: 1. http://youtu.be/oFTmHHCn2-g – Video Demo 2. https://www.openstack.org/summit/portland-2013/session-videos/presentation/interactive-visual-orchestration-with-curvature-and-donabe – Portland presentation 3. https://github.com/CiscoSystems/curvature – original (Rails based) code We’d like to gauge interest from the community on whether this is something people want. Thanks, John, Brad Sam Hey guys, Sorry for my delayed response here…just coming back from maternity leave. I’ve been waiting and hoping since the Portland summit that the curvature work you have done would be brought in to Horizon. A definite +1 from me from a user experience point of view. It would be great to have a solid plan on how this could work with or be additional to the Orchestration and Network Topology pieces that currently exist in Horizon. Let me know if I can help out with any design review, wireframe, or usability testing aspects. Best, Liz ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Cinder plans for kilo: attention new driver authors!
Hey Eduard, We posted our driver cert result by creating a new bugzilla ticket tagging that as driver-cert. https://bugs.launchpad.net/cinder/+bug/1380126 Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Thu, Oct 30, 2014 at 5:55 PM, Eduard Matei eduard.ma...@cloudfounders.com wrote: Hi Mike, I saw your comment on my review, but i need some more info regarding Your driver passes the cert test and the results are posted. I assume you mean running cinder_driver_cert.sh - this is already passing - but how do i get the results posted, and where? I've been looking through some documentation and couldn't find a definitive answer. Thanks Eduard On Thu, Oct 30, 2014 at 9:03 AM, Mike Perez thin...@gmail.com wrote: On 19:41 Thu 04 Sep , Duncan Thomas wrote: Hi during this week's cinder weekly meeting [1], we discussed plans for Kilo, a discussion that started at the mid-cycle meetup [2]. The outcome is that we (the cinder core team and extended community) want to focus on stability and code clean-up in the Kilo release, and paying off some of the technical debt we've built up over the past couple of years [3]. In order to facilitate this, for the Kilo cycle: 1. New drivers must be submitted before K1 in order to be considered. Any driver submitted after this date will be deferred until the L cycle. We encourage submitters to get in early, even if you make K1 there is no guarantee of getting enough reviewer attention to get merged. 2. New features are limited and ideally merged by K2. 3. K3 is dedicated to stability and bug fixing. (Much of this work will happen before K3, but K3 is dedicated to testing and reviewing of it, in preference to anything else. Any driver enhancements required to support pre-existing features will also be considered, but please get them in as early as possible). 4. PoC required before the summit, for any summit session related to new features. 5. There will be a continuing drive for 3rd party CI of every driver in cinder during the Kilo cycle. I'll repost these guidelines and any follow-up clarifications shortly before the summit. Comments / feedback welcome. [1] http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-09-03-16.01.log.html [2] https://etherpad.openstack.org/p/cinder-meetup-summer-2014 [3] https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work Just reiterating points here. From the September 23rd Cinder meeting [1], and verified in the Oct 29th Cinder meeting [2], the community has agreed that new drivers must be submitted *before* K-1 ends. K-1 is expected to end on 12/18, according to the launchpad page [3]. Submitted and qualified for merge means: * Your blueprint for your driver was submitted and approved before 11/15. * Your driver code is posted to gerrit. * Your driver passes the cert test and the results are posted. [4] * Your driver fulfills minimum features. [5] * You have spoken to Duncan (DuncanT- on #openstack-cinder) about your third party ci. [6] To be clear: * Your driver submission must meet *all* the items before the end of k-1. * If your driver is submitted *LATE* in k-1, and meets *all* the items above, but isn't merged, it will be still be considered for merge in k-2 or k-3. However, expect low priority in reviews and not guaranteed for merge in Kilo. * If your driver is submitted after k-1, expect me to reference this email and will request the driver to be submitted in the L release. * This does not include backup drivers. And yes, the Cinder wiki will be updated with this information. [1] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-09-03-16.01.log.html [2] - http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-29-16.00.log.html [3] - https://launchpad.net/cinder/+milestone/kilo-1 [4] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers [5] - http://docs.openstack.org/developer/cinder/devref/drivers.html#minimum-features [6] - https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#Testing_requirements_for_Kilo_release_and_beyond -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- *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
Re: [openstack-dev] [Neutron][Architecture]Suggestions for the third vendors' plugin and driver
+1 I don't think it will be seen as punitive. Vendors can write their plugins or drivers when a deal occurs and they do not need to submit code to community and wait for approving. Being a third party vendor, i do not think this is punitive. OpenStack has already established through processes like cert tests via tempest, external CI, etc. However, waiting for months for reviews and some more days for next round of reviews is really disturbing. Vendor plugins can always always provide repository links, cert tests, external CI logs, pep8 logs, flake8 logs, code coverage stats etc. to confirm if they are abiding by the OpenStack processes. Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Thu, Sep 18, 2014 at 9:56 AM, Germy Lure germy.l...@gmail.com wrote: Hi Salvatore, Thanks for your hyperlink. It's really a monster thread that contains everyone's opinion. But it's useful to me. So, Before we focus on the Neutron core itself, we should firstly release a suite standardized APIs and a framework for vendors' codes. About this job, I think most of it is already OK. We have 20+ monolithic plugins following NB API and plugin framework. We need publish an API doc for internal interface(I prefer to call it SB API, stand on the Neutron core's point to consider, vendors' codes do not belong to core.) and other things unsuitable now. In my opinion, the Neutron core's main responsibility is data model and DB, schedule and dispatch, API and validation, framework and workflow. Some more comments inline. This is a very important discussion - very closely related to the one going on in this other thread http://lists.openstack.org/pipermail/openstack-dev/2014-September/045768.html . Unfortunately it is also a discussion that tends to easily fragment and move in a thousand different directions. A few months ago I was too of the opinion that vendor plugins and drivers were the main reason of unnecessary load for the core team. I still think that they're an unnecessary heavy load, but I reckon the problem does not really lies with open source versus vendor code. It lies in matching people's competencies with subsystems and proper interface across them - as already pointed out in this thread. Yes, it's really important. I have some more comments inline, but unless growing another monster thread I'd rather start a different, cross-project discussion (which will hopefully not become just a cross-project monster thread!) Salvatore On 15 September 2014 08:29, Germy Lure germy.l...@gmail.com wrote: Obviously, to a vendor's plugin/driver, the most important thing is API.Yes? NB API for a monolithic plugin or a service plugin and SB API for a service driver or agent, even MD. That's the basic. Now we have released a set of NB APIs with relative stability. The SB APIs' standardization are needed. The internal interface between the API and the plugins is standardized at the moment through use of classes like [1]. A similar interface exists for ML2 drivers [2]. To the monolithic plugins, [1] is useful. Vendors can implement those APIs and keep their codes locally. At the moment the dispatch of an API call to the plugin or from a plugin to a ML2 driver is purely a local call so these interfaces are working fairly well at the moment. I don't know yet however whether they will be sufficient in case plugins are split into different repos. ML2 Driver maintainers have however been warned in the past that the driver interface is to be considered internal and can be changed at any time. This does not apply to the plugin interface which has been conceived in this way to facilitate the development of out of tree plugins. Indeed, it's difficult to split MDs from ML2 plugin framework. I think it need some adaption. On the other hand, if by SB interfaces you are referring to the RPC interfaces for communicating between the servers and the various plugin, I would say that they should be considered internal at the moment. [1] https://github.com/openstack/neutron/blob/master/neutron/neutron_plugin_base_v2.py#L28 [2] https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/driver_api.py Some comments inline. On Fri, Sep 12, 2014 at 5:18 PM, Kevin Benton blak...@gmail.com wrote: So my suggestion is remove all vendors' plugins and drivers except opensource as built-in. Yes, I think this is currently the view held by the PTL (Kyle) and some of the other cores so what you're suggesting will definitely come up at the summit. Good! The discussion however will not be that different from the one we're seeing on that huge thread on splitting out drivers, which has become in my opinion a frankenthread. Nevertheless, that thread points out that this is far from being merely a neutron topic (despite neutron being the project with the highest number of drivers and plugins). Why do we need a different repo to store vendors' codes?
[openstack-dev] [devstack] [cinder] [driver] Not able to create volume on a 3rd party driver backend
Hi All, While trying to create a volume using my cinder driver (on devstack), i get below issue w.r.t num_attempts. Am i missing any configuration here ? ^[[01;31m2014-09-16 13:20:37.837 TRACE oslo.messaging.rpc.dispatcher ^[[01;35m^[[00m File /opt/stack/cinder/cinder/scheduler/filter_scheduler.py, line 271, in _get_weighted_candidates ^[[01;31m2014-09-16 13:20:37.837 TRACE oslo.messaging.rpc.dispatcher ^[[01;35m^[[00mself._populate_retry(filter_properties, resource_properties) ^[[01;31m2014-09-16 13:20:37.837 TRACE oslo.messaging.rpc.dispatcher ^[[01;35m^[[00m File /opt/stack/cinder/cinder/scheduler/filter_scheduler.py, line 232, in _populate_retry ^[[01;31m2014-09-16 13:20:37.837 TRACE oslo.messaging.rpc.dispatcher ^[[01;35m^[[00mretry['num_attempts'] += 1 ^[[01;31m2014-09-16 13:20:37.837 TRACE oslo.messaging.rpc.dispatcher ^[[01;35m^[[00mKeyError: 'num_attempts' ^[[01;31m2014-09-16 13:20:37.837 TRACE oslo.messaging.rpc.dispatcher ^[[01;35m^[[00m 2014-09-16 13:20:37.841 ^[[01;31mERROR oslo.messaging._drivers.common [^[[01;36mreq-86b97f06-3f32-4107-8f41-e22b9538e73f ^[[00;36m41b264d0e8064e51a8e2e5ab78813c1a db2eb368b9ab4c8b93bb8f765ca55244^[[01;31m] ^[[01;35m^[[01;31mReturning exception 'num_attempts' to caller^[[00m stack trace - http://paste.openstack.org/show/112074/ cinder.conf - http://paste.openstack.org/show/112075/ Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [devstack] [cinder] [driver] Not able to create volume on a 3rd party driver backend
Hi All, If I set *max_attempts = 1* in /etc/cinder/cinder.conf, then the volume creation via 3rd party driver is success. However, this setting does not work for volume deletion. The volume gets deleted at openstack but never executes the driver code. I did above changes based on the error stack trace. */opt/stack/cinder/cinder/scheduler/filter_scheduler.py - _populate_retry* However, i am not sure if this is a bug or an issue of missing configuration. Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Tue, Sep 16, 2014 at 1:34 PM, Amit Das amit@cloudbyte.com wrote: Hi All, While trying to create a volume using my cinder driver (on devstack), i get below issue w.r.t num_attempts. Am i missing any configuration here ? ^[[01;31m2014-09-16 13:20:37.837 TRACE oslo.messaging.rpc.dispatcher ^[[01;35m^[[00m File /opt/stack/cinder/cinder/scheduler/filter_scheduler.py, line 271, in _get_weighted_candidates ^[[01;31m2014-09-16 13:20:37.837 TRACE oslo.messaging.rpc.dispatcher ^[[01;35m^[[00mself._populate_retry(filter_properties, resource_properties) ^[[01;31m2014-09-16 13:20:37.837 TRACE oslo.messaging.rpc.dispatcher ^[[01;35m^[[00m File /opt/stack/cinder/cinder/scheduler/filter_scheduler.py, line 232, in _populate_retry ^[[01;31m2014-09-16 13:20:37.837 TRACE oslo.messaging.rpc.dispatcher ^[[01;35m^[[00mretry['num_attempts'] += 1 ^[[01;31m2014-09-16 13:20:37.837 TRACE oslo.messaging.rpc.dispatcher ^[[01;35m^[[00mKeyError: 'num_attempts' ^[[01;31m2014-09-16 13:20:37.837 TRACE oslo.messaging.rpc.dispatcher ^[[01;35m^[[00m 2014-09-16 13:20:37.841 ^[[01;31mERROR oslo.messaging._drivers.common [^[[01;36mreq-86b97f06-3f32-4107-8f41-e22b9538e73f ^[[00;36m41b264d0e8064e51a8e2e5ab78813c1a db2eb368b9ab4c8b93bb8f765ca55244^[[01;31m] ^[[01;35m^[[01;31mReturning exception 'num_attempts' to caller^[[00m stack trace - http://paste.openstack.org/show/112074/ cinder.conf - http://paste.openstack.org/show/112075/ Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Cinder] [Devstack] - Create Volume is called in an infinite loop
Hi All, I have been running tempest tests on my cinder driver for about a month now. However, since last week i see the create volume logic was attempted thrice by the scheduler after a failure during volume creation. However, i would like the scheduler not to attempt after a failure in volume creation. With this requirement in mind, I modified the /etc/cinder/cinder.conf to have scheduler_max_attempts = 1 my cinder.conf details - http://paste.openstack.org/show/108740/ However, i see that this results in the executing of create volume logic in an endless loop. Please let me know if i have to use any specific scheduler filter etc that does not retry in case of create_volume failures ? Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Cinder plans for kilo: attention new driver authors!
Hi, Thanks for clarification w.r.t cinder drivers. I had submitted the CloudByte driver code during juno and currently grappling with various aspects of setting up the CI for the same. It also requires a copy of tempest logs which also is a in progress item. Will above be automatically eligible for Kilo if above gets done before Kilo freeze dates. Do I need to follow any other processes? On 5 Sep 2014 00:17, Duncan Thomas duncan.tho...@gmail.com wrote: Hi during this week's cinder weekly meeting [1], we discussed plans for Kilo, a discussion that started at the mid-cycle meetup [2]. The outcome is that we (the cinder core team and extended community) want to focus on stability and code clean-up in the Kilo release, and paying off some of the technical debt we've built up over the past couple of years [3]. In order to facilitate this, for the Kilo cycle: 1. New drivers must be submitted before K1 in order to be considered. Any driver submitted after this date will be deferred until the L cycle. We encourage submitters to get in early, even if you make K1 there is no guarantee of getting enough reviewer attention to get merged. 2. New features are limited and ideally merged by K2. 3. K3 is dedicated to stability and bug fixing. (Much of this work will happen before K3, but K3 is dedicated to testing and reviewing of it, in preference to anything else. Any driver enhancements required to support pre-existing features will also be considered, but please get them in as early as possible). 4. PoC required before the summit, for any summit session related to new features. 5. There will be a continuing drive for 3rd party CI of every driver in cinder during the Kilo cycle. I'll repost these guidelines and any follow-up clarifications shortly before the summit. Comments / feedback welcome. [1] http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-09-03-16.01.log.html [2] https://etherpad.openstack.org/p/cinder-meetup-summer-2014 [3] https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work -- Duncan Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder] Cinder plans for kilo: attention new driver authors!
Thanks. I have done that. Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Mon, Sep 8, 2014 at 9:37 AM, Mike Perez thin...@gmail.com wrote: On 17:18 Sun 07 Sep , Amit Das wrote: I had submitted the CloudByte driver code during juno and currently grappling with various aspects of setting up the CI for the same. It also requires a copy of tempest logs which also is a in progress item. Will above be automatically eligible for Kilo if above gets done before Kilo freeze dates. Do I need to follow any other processes? The driver code and cert test should be submitted before K-1. It would be great if you could communicate better that this is in progress. I asked for the cert test results and the status with your CI back on August 10th [1], and assumed this driver submission was already abandoned with no answer. [1] - https://review.openstack.org/#/c/102511/ -- Mike Perez ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] how to provide tests environments for python things that require C extensions
I too agree this can be useful beyond openstack. It will great if one of you (experts) can explain in more details how the python virtual environment is heavyweight than docker containers. I am just a user of devstack without the nitty gritty details of its inner workings. However, I can say that sometimes my Ubuntu VM that has devstack tempest tests running exhaust the entire CPU (make the machine unusable) after the tests are run. Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Fri, Sep 5, 2014 at 9:44 PM, Sean Dague s...@dague.net wrote: On 09/05/2014 12:05 PM, Chris Dent wrote: On Fri, 5 Sep 2014, Monty Taylor wrote: The tl;dr is it's like tox, except it uses docker instead of virtualenv - which means we can express all of our requirements, not just pip ones. Oh thank god[1]. Seriously. jogo started a thread about what matters for kilo and I was going to respond with (amongst other things) get containers into the testing scene. Seems you're way ahead of me. Docker's caching could be a _huge_ win here. [1] https://www.youtube.com/watch?v=om5rbtudzrg across the project. Luckily, docker itself does an EXCELLENT job at handling caching and reuse - so I think we can have a set of containers that something in infra (waves hands) publishes to dockerhub, like: infra/py27 infra/py26 I'm assuming these would get rebuilt regularly (every time global requirements and friends are updated) on some sort of automated hook? Thoughts? Anybody wanna hack on it with me? I think it could wind up being a pretty useful tool for folks outside of OpenStack too if we get it right. Given availability (currently an unknown) I'd like to help with this. I think all this is very cool, I'd say if we're going to put it in gerrit do stackforge instead of openstack/ namespace, because it will be useful beyond us. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Devstack] [Cinder] Registering 3rd party driver as default
Hi folks, I have been trying to run devstack with my cinder driver as the default volume_driver but with no luck. Devstack seems to register the lvm driver as the default always. I have tried below approaches: 1. directly modifying the /etc/cinder/cinder.conf file 2. creating a driver file @ ./devstack/lib/cinder_plugins/driver-name 1. ref - https://review.openstack.org/#/c/68726/ This is my localrc details: http://paste.openstack.org/show/94822/ I run ./unstack.sh then FORCE=yes ./stack.sh This is the cinder.conf that is generated after running above stack.sh. I comment out the [lvmdriver-1] section manually *(not sure if this section needs to be commented)* http://paste.openstack.org/show/94841/ These are portions of c-sch c-vol logs after restarting them in their respective screens. http://paste.openstack.org/show/94842/ Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Devstack] [Cinder] Registering 3rd party driver as default
With further debugging, i find that none of the configuration options present in /etc/cinder/cinder.conf are getting applied. Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Thu, Aug 14, 2014 at 11:40 AM, Amit Das amit@cloudbyte.com wrote: Hi folks, I have been trying to run devstack with my cinder driver as the default volume_driver but with no luck. Devstack seems to register the lvm driver as the default always. I have tried below approaches: 1. directly modifying the /etc/cinder/cinder.conf file 2. creating a driver file @ ./devstack/lib/cinder_plugins/driver-name 1. ref - https://review.openstack.org/#/c/68726/ This is my localrc details: http://paste.openstack.org/show/94822/ I run ./unstack.sh then FORCE=yes ./stack.sh This is the cinder.conf that is generated after running above stack.sh. I comment out the [lvmdriver-1] section manually *(not sure if this section needs to be commented)* http://paste.openstack.org/show/94841/ These are portions of c-sch c-vol logs after restarting them in their respective screens. http://paste.openstack.org/show/94842/ Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Devstack] [Cinder] Registering 3rd party driver as default
Thanks a lot. This worked out like a charm. Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Thu, Aug 14, 2014 at 7:02 PM, Kerr, Andrew andrew.k...@netapp.com wrote: You either need to comment out the enabled_backends line, or you'll want to put something similar to this in your cinder.conf file: [DEFAULT] ... enabled_backends = cloudbyte ... [cloudbyte] volume_driver = volume_driver = cinder.volume.drivers.cloudbyte.cloudbyte.ElasticenterISCSIDriver SAN_IP=20.10.22.245 CB_APIKEY=masQwghrmPOVIqbjyyWKQdg4z4bP2sNZ13fRQyUMwm453PUiYB-xyRSMBDoZeMj6R 0-XU9DCscxMbe3AhleDyQ CB_ACCOUNT_NAME=acc1 TSM_NAME=openstacktsm If you have enabled_backends set then it will only use those driver specs and ignore all driver related details in the DEFAULT section. You also probably want to comment (or remove) the default_volume_type line, unless you plan to create that volume type after the services come up. Andrew Kerr OpenStack QA Cloud Solutions Group NetApp From: Amit Das amit@cloudbyte.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Thursday, August 14, 2014 at 5:37 AM To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Devstack] [Cinder] Registering 3rd party driver as default With further debugging, i find that none of the configuration options present in /etc/cinder/cinder.conf are getting applied. Regards, AmitCloudByte Inc. http://www.cloudbyte.com/ On Thu, Aug 14, 2014 at 11:40 AM, Amit Das amit@cloudbyte.com wrote: Hi folks, I have been trying to run devstack with my cinder driver as the default volume_driver but with no luck. Devstack seems to register the lvm driver as the default always. I have tried below approaches: 1. directly modifying the /etc/cinder/cinder.conf file 2. creating a driver file @ ./devstack/lib/cinder_plugins/driver-name 1. ref - https://review.openstack.org/#/c/68726/ This is my localrc details: http://paste.openstack.org/show/94822/ I run ./unstack.sh then FORCE=yes ./stack.sh This is the cinder.conf that is generated after running above stack.sh. I comment out the [lvmdriver-1] section manually (not sure if this section needs to be commented) http://paste.openstack.org/show/94841/ These are portions of c-sch c-vol logs after restarting them in their respective screens. http://paste.openstack.org/show/94842/ Regards, AmitCloudByte Inc. http://www.cloudbyte.com/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack-Dev] [Cinder] 3'rd party CI systems
Hi John, I guess this is w.r.t 3rd party cinder drivers. I would like some guidance in this regards in form of some links, wiki pages etc. I am currently gathering the driver cert test results i.e. tempest tests from devstack in our environment CI setup would be my next step. Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Tue, Aug 12, 2014 at 6:31 AM, Anita Kuno ante...@anteaya.info wrote: On 08/11/2014 06:26 PM, John Griffith wrote: Hey Cinder folks that have their CI systems up and running; first off... awesome!!! I do have one favor to ask however though. Please, please, please monitor your jobs and if they're not working either fix them or disable them. Currently the it seems that none of the implemented jobs are overly reliable (mostly seeing startup failures). Also, if you're jobs systems aren't actually ready (accessible html link to results files) please disable those as well. Thanks, John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev In support of John's email, I will remind everyone that the sandbox repo is available for testing your third party ci system. Please don't automate the creation of patches, just submit them manually and adding patchsets to current patches is fine. The sandbox repo: http://git.openstack.org/cgit/openstack-dev/sandbox/ Do ask if you need some help or guidance using it. Thanks, Anita. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Jenkins] [Cinder] InvocationError in gate-cinder-python26 python27
Thanks a lot. The recommendations worked fine. Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Fri, Jul 4, 2014 at 3:34 PM, Yuriy Taraday yorik@gmail.com wrote: On Fri, Jul 4, 2014 at 12:57 PM, Amit Das amit@cloudbyte.com wrote: Hi All, I can see a lot of cinder gerrit commits that pass through the gate-cinder-python26 gate-cinder-python27 successfully. ref - https://github.com/openstack/cinder/commits/master Whereas its not the case for my patch https://review.openstack.org/#/c/102511/. I updated the master rebased that to my branch before doing a gerrit review. Am i missing any steps ? Does 'tox -e py26' works on your local machine? It should fail just as one in the gate. You should follow instructions it provides in log just before 'InvocationError' - run tools/config/generate_sample.sh. The issue is that you've added some options to your driver but didn't update etc/cinder/cinder.conf.sample. After generating new sample you should verify its diff (git diff etc/cinder/cinder.conf.sample) and add it to your commit. -- Kind regards, Yuriy. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Jenkins] [Cinder] InvocationError in gate-cinder-python26 python27
Perhaps Jenkins can display a better message to start with. Being new to openstack, i had no clue on what was happening. However, the fix was simple once understood. The current message made me to think something was wrong with jenkins environment setup. Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Fri, Jul 4, 2014 at 5:39 PM, Duncan Thomas duncan.tho...@gmail.com wrote: On 30 June 2014 07:47, Steve Kowalik ste...@wedontsleep.org wrote: Personally, I think generating and comparing a sample config every build is daft, and a sample configuration should be generated during sdist or something. This argument has gone back and forth several times. There is definite value to a reviewer in seeing the sample conf changes - it is usually the first thing I look for with a change, to get a feel what what has been done and look for obvious back compatibility issue, of which there have been lots. Gating on it in its current form is clearly broken since it doesn't take into account the libraries from OSLO might have changed things. Ideally jenkins would, after installing all the deps, git checkout the parent, generate the conf, checkout the change, generate the conf and post up the diffs, but coding that up is tricky. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Jenkins] [Cinder] InvocationError in gate-cinder-python26 python27
Hi Stackers, I have been facing below issues at gate-cinder-python26 gate-cinder-python27 after uploading my patch. I assume this to be an infrastructure issue than an issue with my patch. Can someone please confirm ? . 2014-06-30 05:41:57.704 | check_uptodate.sh: cinder.conf.sample is not up to date. 2014-06-30 05:41:57.704 | check_uptodate.sh: Please run /home/jenkins/workspace/gate-cinder-python26/tools/config/generate_sample.sh. 2014-06-30 05:41:57.705 | ERROR: InvocationError: '/home/jenkins/workspace/gate-cinder-python26/tools/config/check_uptodate.sh' 2014-06-30 05:41:57.705 | ___ summary 2014-06-30 05:41:57.705 | ERROR: py26: commands failed 2014-06-30 05:41:57.707 | + result=1 2014-06-30 05:41:57.708 | + echo 'Begin pip freeze output from test virtualenv:' 2014-06-30 05:41:57.708 | Begin pip freeze output from test virtualenv: 2014-06-30 05:41:57.708 | + echo == 2014-06-30 05:41:57.708 | == 2014-06-30 05:41:57.708 | + .tox/py26/bin/pip freeze . This is my patch url - https://review.openstack.org/#/c/102511/ I have even raised a bug against this - https://bugs.launchpad.net/openstack-ci/+bug/1334623 Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder][volume/manager.py] volume driver mapping
This seems cool. Does it mean the storage vendors write their new drivers just map it from cinder.conf ? Does it involve any changes to devstack as well ? Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Wed, Jun 25, 2014 at 7:22 PM, Duncan Thomas duncan.tho...@gmail.com wrote: That's easy; you don't. The mappings are their because we moved some drivers round during a code cleanup and didn't want old config files to break during an upgrade. The old names have been deprecated since Falsom and finally now removed; new drivers don't need to do any mapping at all. On 25 June 2014 14:29, Yogesh Prasad yogesh.pra...@cloudbyte.com wrote: Hi All, I am observing a bit difference in manager.py file between these branches stable/icehouse and master. In stable/icehouse various driver mapped in manager.py but it is not in master. Please guide me, where i have to map my driver. Thanks Regards, Yogesh Prasad. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder][Driver] Delete snapshot
Hi All, Thanks for clarifying the Cinder behavior w.r.t a snapshot its clones which seems to be independent/decoupled. The current volume its snapshot based validations in Cinder holds true for snapshot its clones w.r.t my storage requirements. Our storage is built on top of ZFS filesystem. The volume - snapshot - clone that I am referring to in turn points to a ZFS dataset - ZFS snapshot - ZFS clone. The best part of ZFS based snapshots clones are : - these are almost instantaneous ( i.e. copy-on-write based copies) - these will not consume any additional (initially) - a clone initially shares all its disk space with the original snapshot, its used property is initially zero. - As changes are made to the clone, it uses more space. - The used property of the original snapshot does not consider the disk space consumed by the clone. Further optimizations i.e. cool feature: - While creating VM clones, a hypervisor driver can delegate part of its cloning process to storage driver hence, the overall VM cloning will be very very fast. Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Thu, Jun 19, 2014 at 9:16 PM, John Griffith john.griff...@solidfire.com wrote: On Tue, Jun 17, 2014 at 10:50 PM, Amit Das amit@cloudbyte.com wrote: Hi Stackers, I have been implementing a Cinder driver for our storage solution facing issues with below scenario. Scenario - When a user/admin tries to delete a snapshot that has associated clone(s), an error message/log should be shown to the user stating that '*There are clones associated to this snapshot. Hence, snapshot cannot be deleted*'. What's the use model of clones associated with the snapshot? What are these clones from a Cinder perspective. Easy answer is: don't create them, but I realize you probably have a cool feature or optimization that you're trying to leverage here. Implementation issues - If Cinder driver throws an Exception the snapshot will have error_deleting status will not be usable. If Cinder driver logs the error silently then Openstack will probably mark the snapshot as deleted. So as others point out, from a Cinder perspective this is what I/we would expect. Scott made some really good points, but the point is we do not want to behave differently for every single driver. The agreed upon mission for Cinder is to actually provide a consistent API and set of behaviors to end users regardless of what backend device they're using (in other words that should remain pretty much invisible to the end-user). What do you use the Clones of the Snapshot for? Maybe we can come up with another approach that works and keeps consistency in the API. What is the appropriate procedure that needs to be followed for above usecase. Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Cinder][Driver] Delete snapshot
Hi Stackers, I have been implementing a Cinder driver for our storage solution facing issues with below scenario. Scenario - When a user/admin tries to delete a snapshot that has associated clone(s), an error message/log should be shown to the user stating that '*There are clones associated to this snapshot. Hence, snapshot cannot be deleted* '. Implementation issues - If Cinder driver throws an Exception the snapshot will have error_deleting status will not be usable. If Cinder driver logs the error silently then Openstack will probably mark the snapshot as deleted. What is the appropriate procedure that needs to be followed for above usecase. Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Proposal to support new Cinder driver for CloudByte's Elastistor
Hi Team, We have implemented a CINDER driver for our QoS aware storage solution (CloudByte Elastistor). We would like to integrate this driver code with the next version of OpenStack (Havana). Please let us know the approval processes to be followed for this new driver support. Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Proposal to support new Cinder driver for CloudByte's Elastistor
Thanks a lot... This should give us a head start. Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Tue, Aug 13, 2013 at 5:14 PM, Thierry Carrez thie...@openstack.orgwrote: Amit Das wrote: We have implemented a CINDER driver for our QoS aware storage solution (CloudByte Elastistor). We would like to integrate this driver code with the next version of OpenStack (Havana). Please let us know the approval processes to be followed for this new driver support. See https://wiki.openstack.org/wiki/Release_Cycle and https://wiki.openstack.org/wiki/Blueprints for the beginning of an answer. Note that we are pretty late in the Havana cycle with lots of features which have been proposed a long time ago still waiting for reviews and merging... so it's a bit unlikely that a new feature would be added now to that already-overloaded backlog. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Proposal to support new Cinder driver for CloudByte's Elastistor
Thanks John for the updates. I shall work towards setting up the Blueprint Gerrit. We have the code ready but pretty late in participating with the community. Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Tue, Aug 13, 2013 at 8:31 PM, John Griffith john.griff...@solidfire.comwrote: Hi Amit, I think part of what Thierry was eluding to was the fact that feature freeze for Grizzly is next week. Also in the past we've been trying to make sure that folks did not introduce BP's for new drivers in the last release mile-stone. There are other folks that are in this position however they've also proposed their BP's for their driver and sent updates to the Cinder team since H1. That being said, if you already have working code that you think is ready and can be submitted we can see what the rest of the Cinder team thinks. No promises though that your code will make it in, there are a number of things already in process that will take priority in terms of review time etc. Thanks, John On Tue, Aug 13, 2013 at 8:42 AM, Amit Das amit@cloudbyte.com wrote: Thanks a lot... This should give us a head start. Regards, Amit *CloudByte Inc.* http://www.cloudbyte.com/ On Tue, Aug 13, 2013 at 5:14 PM, Thierry Carrez thie...@openstack.orgwrote: Amit Das wrote: We have implemented a CINDER driver for our QoS aware storage solution (CloudByte Elastistor). We would like to integrate this driver code with the next version of OpenStack (Havana). Please let us know the approval processes to be followed for this new driver support. See https://wiki.openstack.org/wiki/Release_Cycle and https://wiki.openstack.org/wiki/Blueprints for the beginning of an answer. Note that we are pretty late in the Havana cycle with lots of features which have been proposed a long time ago still waiting for reviews and merging... so it's a bit unlikely that a new feature would be added now to that already-overloaded backlog. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
