[openstack-dev] Facing an issue in swift
Hi all, Question: Endpoint for object-store not found - have you specified a region? I am facing this issue while integrating swift with keystone in havana: I changed proxy-server.conf file with the below contents [pipeline:main] pipeline = authtoken keystoneauth proxy-logging proxy-server [filter:authtoken] paste.filter_factory = keystoneclient.middleware.auth_token:filter_factory auth_host = controller auth_port = 35357 auth_protocol = http auth_uri = http://10.233.52.110:35357/v2.0 admin_tenant_name = admin admin_user = admin admin_password = ADMIN_PASS cache = swift.cache include_service_catalog = False [filter:keystoneauth] use = egg:swift#keystoneauth operator_roles = admin, swiftoperator and restarted all the swift services, while executing swift commands output is Endpoint for object-store not found - have you specified a region? Can anyone help me on this issue ? And I referred the below link: http://docs.openstack.org/developer/swift/overview_auth.html Thanks and Regards, Sowmya Nethi sowmya_ne...@persistent.co.in | Tel: +91(40)674 42026 Persistent Systems Ltd. | Partners in Innovation | www.persistentsys.comhttp://www.persistentsys.com/ DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Collector no recheck the db status
On Wed, Apr 02 2014, dong jia wrote: I found that when collector service starting, if the db has not yet ready, it will log an error info like 'Could not load 'database': could not connect to...' but the service still goes on. Later when the db is ready, but there are no mechanisms to check the db status and reconnect it. so the collector service keeps useless to record the data. I wonder whether this is normal or an issue. That sounds like an issue. I would expect the SQL driver to be better in this case than MongoDB, but still, just open a bug report. -- Julien Danjou ;; Free Software hacker ;; http://julien.danjou.info signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Mistral] How Mistral handling long running delegate tasks
On 02 Apr 2014, at 13:38, Kirill Izotov enyk...@stackstorm.com wrote: I agree that we probably need new engine for that kind of changes and, as Renat already said in another thread, lazy model seems to be more basic and it would be easier to build sync engine on top of that rather than other way around. Yes, it will entail a lot of changes in engines that are currently here, but it seems like the only way to get something that would fit us both. Since it seems like we are getting some kind of agreement here, we should probably start shifting to the plane where we discuss the design of the new engine, rather than the need of one. The idea has been spread over to many places, so i'll try to gather it back. Lazy engine should be async and atomic, it should not have its own state, instead it should rely on on some kind of global state (db or in-memory, depending on a type of application). I should have at least two methods: run and task_complete. Run method should calculate the first batch of tasks and schedule them to execution (either put them in queue or spawn the threads... or send a pidgin, i insist =). Task_complete should mark a certain task to be completed and then schedule the next batch of tasks that became available due to resolution of this one. Then, on top of it you can build sync engine by introducing Futures. You are using async.run() to schedule the tasks by transforming them to Futures and then starting a loop, checking Futures for completion and sending their results to async.task_complete() which would produce even more Futures to check over. Just the same way TaskFlow do it right now. On the Mistral side we are using Lazy engine by patching async.run to the API (or engine queue) and async.task_complete to the worker queue result channel (and the API for long running tasks). We still sharing the same graph_analyzer, but instead of relying on loop and Futures, we are handling execution in a scalable and robust way. The reason i'm proposing to extract Futures from async engine is because they won't work if we have multiple engines that should handle the task results concurrently (and without that there will be no scalability). I agree with all the major points here. It sounds like a plan. What i see is bothering Joshua is that worker that handles long running task may just die in a process and there is no way for us to know for sure is it still working or not. It is more important for sync engine because without that it would just hang forever (though it is not clear do sync engine needs long running tasks at all?). In case of sync engine, the role of watch-dog may be performed by the loop, while in case of Mistral it might be a separate process (though i bet there should be something for resending the message in the RabbitMQ itself). The common solution is not necessary here. As for not loosing messages (resending them to the queue) that’s why I mentioned message acknowledgement ([0]). Rabbit does it automatically if a message that has been pulled out of queue should be acknowledged and the corresponding rabbit client connection dies before the client acknowledges the message (at this point there’s a guarantee it’s been processed). It works this way now in Mistral. A slight problem with the current Mistral implementation is that engine works as follows when starting a workflow: 1. Start DB Transaction Make all smart logic and DB operations (updating persistent state of tasks and execution) Commit DB Transaction 2. Submit task messages to MQ. So there’s a window between steps 1 and 2 when if the system crashes DB state won’t be consistent with the state of the MQ. From a worker perspective looks like this problem doesn’t exist (at least we thought through it and didn’t find any synchronisation windows). Initially step 2 was a part of step 1 (a part of DB TX) and it would solve the problem but it’s generally a bad pattern to have interprocess communication inside DB TX so we got rid of it. So this seems to me the only problem with the current architecture, we left it as it was and were going to get back to it after POC. I assume this might be describing the reason why Josh keeps talking about ‘jobboard’ thing, but I just don’t have enough details at this point to say if that’s what we need or not. One solution I see here is just to consider this situation exceptional from workflow execution model perspective and apply policies to tasks that are persisted in DB but not submitted to MQ (what you guys discussed about retries and all that stuff..). So our watch-dog process could just resubmit tasks that have been hanging in DB longer than a configured period with the state IDLE. Something like that. [0] http://www.rabbitmq.com/tutorials/tutorial-two-python.html Renat Akhmerov @ Mirantis Inc. ___ OpenStack-dev mailing list
[openstack-dev] Nova Live Migration issue
Hi all I'm following the below link for VM migration from one compute node to the another from the controller node using devstack .. http://www.mirantis.com/blog/tutorial-openstack-live-migration-with-kvm-hypervisor-and-nfs-shared-storage/ I'm able to migrate the instance from one compute node to the other compute node using the below command. nova live-migration b33b23f8-4510-4ed3-8cd1-2d68c8186e40 salaria1 The instance is able to migrate properly and that i have confirmed using the sudo virsh list command over the newer compute node. However the problem is when i type nova list at the same time.The status of instance is stuck at migrating and does not changes even after some time. Moreover when i type nova show instance -id command,the old host of the instance is reflected instead of the new one. Please help regarding this. Thanks Abhishek Jain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Nova Live Migration issue
Hi! Can you show libvirt logs? Nikolay Starodubtsev Software Engineer Mirantis Inc. Skype: dark_harlequine1 2014-04-02 11:55 GMT+04:00 abhishek jain ashujain9...@gmail.com: Hi all I'm following the below link for VM migration from one compute node to the another from the controller node using devstack .. http://www.mirantis.com/blog/tutorial-openstack-live-migration-with-kvm-hypervisor-and-nfs-shared-storage/ I'm able to migrate the instance from one compute node to the other compute node using the below command. nova live-migration b33b23f8-4510-4ed3-8cd1-2d68c8186e40 salaria1 The instance is able to migrate properly and that i have confirmed using the sudo virsh list command over the newer compute node. However the problem is when i type nova list at the same time.The status of instance is stuck at migrating and does not changes even after some time. Moreover when i type nova show instance -id command,the old host of the instance is reflected instead of the new one. Please help regarding this. Thanks Abhishek Jain ___ 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] [Neutron LBaaS] Need help with LBaaS drivers
Hi Vijay,
Currently you may follow two ways in writing an LBaaS driver:
1) write it from scratch (like Radware, Netscaler, Embrane drivers) -
in this case your driver should inherit
abstract_driver.LoadBalancerAbstractDriver
and
will be running on Neutron service process, LBaaS agent won't be used.
So you should restart not q-lbaas but q-svc process in order for new
driver to be used and it should work with the steps you've described.
2) leverage
neutron/services/loadbalancer/drivers/common/agent_drive_base.py framework
and in fact write only device driver which inheritits
neutron.services.loadbalancer.agent.agent_device_driver.AgentDeviceDriver.
This is how HAProxy driver is implemented, please see
neutron/services/loadbalancer/drivers/haproxy/plugin_driver.py
and namespace_driver.py (this is device driver).
Along with updating service_provider in neutron.conf you should also
add your device driver to lbaas_agent.ini file (again please check how it
is done for haproxy)
In this case your driver will be running on LBaaS agent and you should
restart both q-svc and q-lbaas.
Generally, the second approach is preferable as it's better scalable and
provides you a built-in async mechanism.
Thanks,
Oleg
On Wed, Apr 2, 2014 at 5:44 AM, Vijay B os.v...@gmail.com wrote:
Hi,
I'm trying to understand how LBaaS drivers work and so am attempting to
write a dummy driver that does nothing for now, but instead of loading my
dummy driver, neutron always loads the HAProxy namespace driver. These are
the steps I followed:
1) I created a new directory neutron/services/loadbalancer/drivers/dummy/,
and in that directory I put in a new file dummy_driver.py, which
basically has a class class
DummyPluginDriver(abstract_driver.LoadBalancerAbstractDriver):
and has empty __init__(), create_vip(), delete_vip() etc functions.
2) I'm testing using a devstack setup, so I also edited the
/etc/neutron/neutron.conf file, commenting out the default loadbalancer
driver entry for HAProxy, and added a line for my dummy driver as follows:
service_provider=LOADBALANCER:Dummy:neutron.services.loadbalancer.drivers.dummy.dummy_driver.DummyPluginDriver:default
3) I created a /etc/neutron/services/loadbalancer/dummy/lbaas_agent.ini
directory/file
I simply copied over the haproxy's lbaas_agent.ini file and changed
[haproxy] to [dummy]
and then I restarted the q-lbaas service using cd /opt/stack/neutron
python /usr/local/bin/neutron-lbaas-agent --config-file
/etc/neutron/neutron.conf
--config-file=/etc/neutron/services/loadbalancer/dummy/lbaas_agent.ini
However, I see that the default HAProxyNS driver is still being loaded
When I put a breakpoint in loadbalancer/agent/agent_manager.py:86, I see
this (relevant text marked in red):
2014-03-31 13:47:16.998 DEBUG neutron.common.utils [-] Reloading cached
file /etc/neutron/policy.json from (pid=28405) read_cached_file
/opt/stack/neutron/neutron/common/utils.py:53
2014-03-31 13:47:16.998 DEBUG neutron.policy [-] Loading policies from
file: /etc/neutron/policy.json from (pid=28405) _set_rules
/opt/stack/neutron/neutron/policy.py:89
/opt/stack/neutron/neutron/services/loadbalancer/agent/agent_manager.py(86)_load_drivers()
- self.device_drivers = {}
(Pdb) l
81 # pool_id-device_driver_name mapping used to store known
instances
82 self.instance_mapping = {}
83
84 def _load_drivers(self):
85 import pdb; pdb.set_trace()
86 - self.device_drivers = {}
87 for driver in self.conf.device_driver:
88 try:
89 driver_inst = importutils.import_object(
90 driver,
91 self.conf,
(Pdb) self.conf.device_driver
['neutron.services.loadbalancer.drivers.haproxy.namespace_driver.HaproxyNSDriver']
(Pdb)
I'm not sure what I'm doing wrong - am I missing something that needs to
be done within the dummy driver itself? (in dummy_driver.py?). Should I
register some opts or similar?
Any help would be much appreciated!
Thanks,
Regards,
Vijay
___
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] [tempest][scenario] independece test between Stack and backing services?
Hello, Igawa-san Thanks for pointing out Tempest principles. I wasn't aware of them. ok, I'll probably use the current test cases with manually stopping services. I'm checking with Temest(icehouse) and if I write or think up something useful, I'll be back. Also Grenade, too. :) Thank you for valuable advices, - Tomoya Goto Hi, On 04/02, Tomoya Goto wrote: Thanks for quick replies Igawa-san and Mr.Sean! :) and sorry foy my slow reply :( np :) The task I wantetd to conduct is not only for upgrading but also for rather small maintenace, say stopping openstack-cinder* for changing configuration. Now, Grenade is for upgrade purpose but not for such small maintenace, right? So I think tempest is more suitable than Grenade for such task. what do you say? This kind (fault injection?) of tests that you said are interesting and we should have them in future. But Tempest should not operate OpenStack components directly. e.g. stop/start Cinder/Glance/Nova services. This is one of design principles[1]. So I think we need a new project for these types of tests or need to change the principles. [1] http://docs.openstack.org/developer/tempest/overview.html#design-principles Thanks, -- Masayuki Igawa - Tomoya Goto You are correct. The testing we do for this is in Grenade, which we run in the gate. Grenade tests an upgrade from last stable release to current master. It creates a few resources before the upgrade, and fails if those are interupted after the upgrade. Grenade is still pretty light on the number of resources it creates before the upgrade, and is definitely a place where enhancement is welcome. -Sean On 04/01/2014 04:18 AM, Masayuki Igawa wrote: Hi Goto-san, I think this is an interesting test case. But AFAIK, Tempest and its scenario tests don't have such test cases now, and we can't stop the OpenStack processes through Tempest. Do you know Grenade[1]? I think Grenade is the only one upgrading test in the OpenStack community now. So I guess Grenade can test these kind of tests but not yet though. [1] https://wiki.openstack.org/wiki/Grenade On 04/01, 後藤 僚哉 wrote: Hello everyone. I'm looking for an independence test between an OpenStack environment and virtual environments. In case of updating an openstack environment, you need to stop each OpenStack process, but you don't want the instances to be affected by OpenStack outages. So before maintenane, you want to make sure OpenStack and backing services(KVM, OVS, storage,.) are separate. For example. 1) Creating a virtual environment on a OpenStack environment. this includes Nova instances, Neutron L2/3 networks, Cinder volumes and etc. I'd like to clarify more. Do you mean OpenStack on OpenStack environment? Or just mean VMs on OpenStack env? I meant just VMs on OpenStack env. When you stop some processes for update, say openstack-cinder-*, you want to make sure it won't disconnect volume/VM. Thanks, I got it. 2) Stopping one or more OpenStack's processes. Currently, Tempest can't stop the OpenStack processes. Because Tempest can operate OpenStack components through OpenStack APIs only for now. oh yes. Just like I feard. Thanks, -- Masayuki Igawa 3) Running this test, and checking that each resource doesn't stop. 4) Updating an OpenStack, editing configurations or etc. I assume such test is coverd by tempest. Dose Tempest have those test methods? or if not, do you think it's going to be handy if I make such test? Best regards, Tomoya Goto ___ 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] [Heat] PTL Candidacy
Hello all, I'd like announce my candidacy for Heat PTL. It's been a pleasure to be part of such a great team for about a year now, and that's the main driver for me to want to represent all of you. I trust that as a team we'll continue do a good job delivering nice software, and I hope I could become the team delegate for the next 6 months. If I had to choose my slogan for this period, it would be Less features, more users. I think we've reached the point where Heat fills a solid portion of the use cases it aimed at the beginning, so we should focus on everything else: * It starts by more functional testing, via more tempests and grenade integration to make sure upgrades are fine. I hope it'll continue to improve our stability * Then I'd like to look at performance, to make sure we're good enough so that people doesn't notice Heat when deploying it * We should also maintain our efforts on documentation * Finally, we should support template authors, by talking to the OpenStack community (TripleO, Trove, Murano,...) but also outside to application developers. I hope we can push contributions to heat-templates (or another repository) for better community interaction. I'm willing to learn if I'll actually have some time to do more than one of those things while holding the position! My commits: https://review.openstack.org/#/q/owner:therve,n,z And my reviews: https://review.openstack.org/#/q/reviewer:therve,n,z Thanks, -- Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] PTL Candidacy
confirmed On 04/02/2014 11:06 AM, Thomas Herve wrote: Hello all, I'd like announce my candidacy for Heat PTL. It's been a pleasure to be part of such a great team for about a year now, and that's the main driver for me to want to represent all of you. I trust that as a team we'll continue do a good job delivering nice software, and I hope I could become the team delegate for the next 6 months. If I had to choose my slogan for this period, it would be Less features, more users. I think we've reached the point where Heat fills a solid portion of the use cases it aimed at the beginning, so we should focus on everything else: * It starts by more functional testing, via more tempests and grenade integration to make sure upgrades are fine. I hope it'll continue to improve our stability * Then I'd like to look at performance, to make sure we're good enough so that people doesn't notice Heat when deploying it * We should also maintain our efforts on documentation * Finally, we should support template authors, by talking to the OpenStack community (TripleO, Trove, Murano,...) but also outside to application developers. I hope we can push contributions to heat-templates (or another repository) for better community interaction. I'm willing to learn if I'll actually have some time to do more than one of those things while holding the position! My commits: https://review.openstack.org/#/q/owner:therve,n,z And my reviews: https://review.openstack.org/#/q/reviewer:therve,n,z Thanks, signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] FreeBSD/bhyve support for nova with libvirt
On Tue, Apr 01, 2014 at 08:22:37PM +0200, Michał Dubiel wrote: OK, thanks Russell and Daniel for your suggestions. Stackforge sounds reasonable for the time being, though it's not perfect as it doesn't prevent from occasional conflicts we may hit while pulling changes from the original Nova repository to our clone. An example is code that is not pure additions, but changes to the existing Nova source code (for instance libvirt vif driver calls directly code from linux_net module, which should be abstracted out, and proper for the given platform implementation should be used automatically). This sort of problems apply to the entire FreeBSD platform regardless which one: bhyve or qemu is used. If you have a need todo general refactoring like that, then I'd suggest those particular patches could actually be submitted straight to Nova mainline, since they are valid/useful for multiple libvirt platforms, even ignoring bhyve. Just have the stuff that's truly bhyve / FreeBSD specific in your separate tree. That should hopefully reduce the amount of pain you encur. So in this example, you could introduce the abstraction layer for the networking setup APIs into mainline GIT, and update libvirt / linux_net code to work with it. Then just have the bhyve + freebsd networking stuff in your separate repo. Last question. May we expect review help while the code is in the Stackforge, or we have to wait until all features are finished and it's accepted to be reviewed in Nova repo? Given our general code review overload I think it is unlikely you'll get any frequent / detailed code review, except for refactoring bits you submit to nova git directly. As libvirt maintainer though, I'd be happy to take a look at what you are developing and offer advice and high level review to make sure you are heading in a direction that it sensible for the eventual nova merge. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Tuskar][Horizon] Javascript linter
Hi all, Recently we have been discussing the topic of Javascript linters for Horizon and Tuskar-UI with Radomir, and he told me that JSLint and JSHint can not be integrated into the test environment due to some license issues. I did some search and found Closure Linter [1] by Google which might be an alternative, and I wanted to get some feedback on it. Pros: - Open source, Apache License - Written in Python, available from pip - Used by Google, so probably it's production ready (or at least beta) Cons: - Javascript style is not configurable, it is hard coded to check The Google JavaScript Style [2], which might not exactly match OpenStack's desired coding style - It could take a long time to fix all js code to be accepted by the linter Does it look like something we could use? Thanks, Peter [1] https://developers.google.com/closure/utilities/ [2] http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Nova Live Migration issue
Can you confirm that it's no longer running on the source node and only running on the destination node? What's your libvirt version? Possibly the libvirt monitor lost connection and didn't complete the post-migration which would update the db. As Nikolay suggested, the libvirt.log would tell more, good if it also had debug turned on. From: Nikolay Starodubtsev [mailto:nstarodubt...@mirantis.com] Sent: 02 April 2014 09:01 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Nova Live Migration issue Hi! Can you show libvirt logs? Nikolay Starodubtsev Software Engineer Mirantis Inc. Skype: dark_harlequine1 2014-04-02 11:55 GMT+04:00 abhishek jain ashujain9...@gmail.commailto:ashujain9...@gmail.com: Hi all I'm following the below link for VM migration from one compute node to the another from the controller node using devstack .. http://www.mirantis.com/blog/tutorial-openstack-live-migration-with-kvm-hypervisor-and-nfs-shared-storage/ I'm able to migrate the instance from one compute node to the other compute node using the below command. nova live-migration b33b23f8-4510-4ed3-8cd1-2d68c8186e40 salaria1 The instance is able to migrate properly and that i have confirmed using the sudo virsh list command over the newer compute node. However the problem is when i type nova list at the same time.The status of instance is stuck at migrating and does not changes even after some time. Moreover when i type nova show instance -id command,the old host of the instance is reflected instead of the new one. Please help regarding this. Thanks Abhishek Jain ___ 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-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Tempest][qa] : backporting Test Security Groups Basic Ops in stable/havana ?
Hi everyone, I'm interested in having the Tempest scenario Test Security Groups Basic Ops available in the stable/Havana branch . This scenario is nice for acceptance tests and it's running fine with an Havana deployment. Can someone in the Stable-maint team can backport it from master to stable/Havana ? If it's OK for you of course :) Best Regards, Julien LELOUP julien.lel...@3ds.com This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged. If you are not one of the named recipients or have received this email in error, (i) you should not read, disclose, or copy it, (ii) please notify sender of your receipt by reply email and delete this email and all attachments, (iii) Dassault Systemes does not accept or assume any liability or responsibility for any use of or reliance on this email. For other languages, go to http://www.3ds.com/terms/email-disclaimer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [climate] PTL Candidacy
Confirmed. On Wed, Apr 2, 2014 at 12:11 AM, Dina Belova dbel...@mirantis.com wrote: Howdy, folks! I'd like to announce my wish to continue being Climate PTL during next Juno release cycle. I have been working on Climate initiative since really early stages of its development and was leading the subteam responsible for the implementation of core Climate functionality and virtual reservations possibility. I was chosen as a technical leader for this project about 4 months ago and would like to continue being the one. During previous development cycle I was really focused on making Climate work for both original use cases and improving not only its functionality but also a technical level, integrating with oslo.messaging and improving documentation coverage. We had our first release created, and currently I'm coordinating efforts of all our contributors trying to help them making Climate better without overlaps and unnecessary actions. For Juno release cycle I'd love to continue my Climate activities including code reviews, release management, IRC meeting holding and coordination. As for Climate itself I'm planning to present it on Atlanta summit and decide its overall future with OS community, focus on implementing new resources reservations and new flow for leases creation, not forgetting about energy efficiency feature and Tempest testing. My changes history [1] and reviews history [2] might be found below. [1] http://stackalytics.com/?release=allmetric=commitsproject_type=allmodule=climatecompany=user_id=dbelova [2] http://stackalytics.com/?release=allmetric=marksproject_type=allmodule=climatecompany=user_id=dbelova Thanks! Dina ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Missleading and hardly parseable default neutron config files
Hi, The default neutron configuration files aren't useable by default. So, I'm heavily patching them in my Debian package. This isn't an idea situation already, especially that I have to rebase my patch on each (pre-)release. Though here, if I'm not mistaking, we're having a completely *wrong* example as a comment. From the default neutron.conf: # Example: service_plugins = router,firewall,lbaas,vpnaas,metering AFAIU, router and firewall aren't valid values (they make neutron-db-manage crash dump for example), and we should use instead something like: service_plugins = l3_router,fwaas,lbaas,vpnaas,metering Am I mistaking? If no, then how come neutron.conf advertizes for non-working directive values? Also, and it's been like this for quite long: what Neutron ships as configuration file isn't parseable in a satisfying way. For example, everywhere in the files, we have things like this: # Example: # connection = mysql://root:pass@127.0.0.1:3306/neutron # Replace 127.0.0.1 above with the IP address of the database used # by the main neutron server. (Leave it as is if the database runs # on this host.) # connection = sqlite:// (above comments rewraped to make it fit in this message) How exactly a script is supposed to make the difference between the 2 commented-out connection directives? They both look like occurrences of the same directives, and there's no way to distinguish the first one (and example) from the 2nd one (a commented out directive). Could we instead use something like this instead? -# Example: -# connection = mysql://root:pass@127.0.0.1:3306/neutron +# Example: connection = mysql://root:pass@127.0.0.1:3306/neutron It'd be nice if these changes could make it to the Icehouse release. Thoughts anyone? Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tempest][scenario] independece test between Stack and backing services?
Fault injection is a problem I've been thinking about, though I don't have time to dive into it any time soon. But I'll share my ideas in case they are interesting. I think we need a Fault Injection Service for OpenStack. It would act like many of the other OpenStack services, have an API service, and a worker on every node. It would be our own kind of chaos monkey, except very programmable. It would look like any multi host service, communicating over RPC between API and the nodes. The Fault injection service would have the ability to kill process on the hosts (libvirt, nova-compute, c-vol). It would also have the ability to delete did data (simulating a hardware fault). We could definitely use something like this to also signal a service restart, or some other behind the scenes action that we'd expect would be regularly happening. If we had a Fault Injection service, then we could have a class of tests (possibly in Tempest, possibly in another place) which would start resources with the OpenStack API, then inject faults, then continue along the way. I feel like Juno is too soon for this, as we have lots of other issues to address. However, K might work. That being said, if anyone wants to dive in early, have at. The important thing would be that this has REST API, and that it be multi node. -Sean On 04/02/2014 04:37 AM, Tomoya Goto wrote: Hello, Igawa-san Thanks for pointing out Tempest principles. I wasn't aware of them. ok, I'll probably use the current test cases with manually stopping services. I'm checking with Temest(icehouse) and if I write or think up something useful, I'll be back. Also Grenade, too. :) Thank you for valuable advices, - Tomoya Goto Hi, On 04/02, Tomoya Goto wrote: Thanks for quick replies Igawa-san and Mr.Sean! :) and sorry foy my slow reply :( np :) The task I wantetd to conduct is not only for upgrading but also for rather small maintenace, say stopping openstack-cinder* for changing configuration. Now, Grenade is for upgrade purpose but not for such small maintenace, right? So I think tempest is more suitable than Grenade for such task. what do you say? This kind (fault injection?) of tests that you said are interesting and we should have them in future. But Tempest should not operate OpenStack components directly. e.g. stop/start Cinder/Glance/Nova services. This is one of design principles[1]. So I think we need a new project for these types of tests or need to change the principles. [1] http://docs.openstack.org/developer/tempest/overview.html#design-principles Thanks, -- Masayuki Igawa - Tomoya Goto You are correct. The testing we do for this is in Grenade, which we run in the gate. Grenade tests an upgrade from last stable release to current master. It creates a few resources before the upgrade, and fails if those are interupted after the upgrade. Grenade is still pretty light on the number of resources it creates before the upgrade, and is definitely a place where enhancement is welcome. -Sean On 04/01/2014 04:18 AM, Masayuki Igawa wrote: Hi Goto-san, I think this is an interesting test case. But AFAIK, Tempest and its scenario tests don't have such test cases now, and we can't stop the OpenStack processes through Tempest. Do you know Grenade[1]? I think Grenade is the only one upgrading test in the OpenStack community now. So I guess Grenade can test these kind of tests but not yet though. [1] https://wiki.openstack.org/wiki/Grenade On 04/01, 後藤 僚哉 wrote: Hello everyone. I'm looking for an independence test between an OpenStack environment and virtual environments. In case of updating an openstack environment, you need to stop each OpenStack process, but you don't want the instances to be affected by OpenStack outages. So before maintenane, you want to make sure OpenStack and backing services(KVM, OVS, storage,.) are separate. For example. 1) Creating a virtual environment on a OpenStack environment. this includes Nova instances, Neutron L2/3 networks, Cinder volumes and etc. I'd like to clarify more. Do you mean OpenStack on OpenStack environment? Or just mean VMs on OpenStack env? I meant just VMs on OpenStack env. When you stop some processes for update, say openstack-cinder-*, you want to make sure it won't disconnect volume/VM. Thanks, I got it. 2) Stopping one or more OpenStack's processes. Currently, Tempest can't stop the OpenStack processes. Because Tempest can operate OpenStack components through OpenStack APIs only for now. oh yes. Just like I feard. Thanks, -- Masayuki Igawa 3) Running this test, and checking that each resource doesn't stop. 4) Updating an OpenStack, editing configurations or etc. I assume such test is coverd by tempest. Dose Tempest have those test methods? or if not, do you think it's going to be handy if I make such test? Best regards, Tomoya Goto
Re: [openstack-dev] Missleading and hardly parseable default neutron config files
Hi Thomas, it probably won't be a bad idea if you can share the patches you're applying to the default configuration files. I think all distros are patching them anyway, so this might allow us to provide mostly ready to use config files. Is there a chance you can push something to gerrit? Salvatore On 2 April 2014 12:12, Thomas Goirand z...@debian.org wrote: Hi, The default neutron configuration files aren't useable by default. So, I'm heavily patching them in my Debian package. This isn't an idea situation already, especially that I have to rebase my patch on each (pre-)release. Though here, if I'm not mistaking, we're having a completely *wrong* example as a comment. From the default neutron.conf: # Example: service_plugins = router,firewall,lbaas,vpnaas,metering AFAIU, router and firewall aren't valid values (they make neutron-db-manage crash dump for example), and we should use instead something like: service_plugins = l3_router,fwaas,lbaas,vpnaas,metering Am I mistaking? If no, then how come neutron.conf advertizes for non-working directive values? Also, and it's been like this for quite long: what Neutron ships as configuration file isn't parseable in a satisfying way. For example, everywhere in the files, we have things like this: # Example: # connection = mysql://root:pass@127.0.0.1:3306/neutron # Replace 127.0.0.1 above with the IP address of the database used # by the main neutron server. (Leave it as is if the database runs # on this host.) # connection = sqlite:// (above comments rewraped to make it fit in this message) How exactly a script is supposed to make the difference between the 2 commented-out connection directives? They both look like occurrences of the same directives, and there's no way to distinguish the first one (and example) from the 2nd one (a commented out directive). Could we instead use something like this instead? -# Example: -# connection = mysql://root:pass@127.0.0.1:3306/neutron +# Example: connection = mysql://root:pass@127.0.0.1:3306/neutron It'd be nice if these changes could make it to the Icehouse release. Thoughts anyone? Cheers, Thomas Goirand (zigo) ___ 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] Documenting FWaaS
Hi! I am currently documenting FWaaS for development purposes. My focus is to have a detailed end-to-end flow (from plugin to driver. I thought it would be a good idea to share my deliverables (document + images) with the community and have feedback from the community. Since I am a newcomer to openstack-dev I am not sure what will be the proper location where to place these deliverables. Thanks Israel Ziv (israel@huawei.commailto:israel@huawei.com ) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Facing an issue in swift
In my experience 'Endpoint for object-store not found - have you specified a region?' can be returned by swift client if: (a) You have specified a region that isn't found among the service endpoints e.g. % swift --os-auth-url http://example:5000/v2.0 --os-password=testing stat --os-username=tester --os-tenant-name=test --os-region-name=foo Endpoint for object-store not found - have you specified a region? Or (b) you did not specify a tenant-name or tenant-id e.g. % swift --os-auth-url http://example:5000/v2.0 --os-password=testing stat --os-username=tester Endpoint for object-store not found - have you specified a region? From: Sowmya Nethi [mailto:sowmya_ne...@persistent.co.in] Sent: 02 April 2014 07:43 To: openstack-dev@lists.openstack.org Subject: [openstack-dev] Facing an issue in swift Hi all, Question: Endpoint for object-store not found - have you specified a region? I am facing this issue while integrating swift with keystone in havana: I changed proxy-server.conf file with the below contents [pipeline:main] pipeline = authtoken keystoneauth proxy-logging proxy-server [filter:authtoken] paste.filter_factory = keystoneclient.middleware.auth_token:filter_factory auth_host = controller auth_port = 35357 auth_protocol = http auth_uri = http://10.233.52.110:35357/v2.0 admin_tenant_name = admin admin_user = admin admin_password = ADMIN_PASS cache = swift.cache include_service_catalog = False [filter:keystoneauth] use = egg:swift#keystoneauth operator_roles = admin, swiftoperator and restarted all the swift services, while executing swift commands output is Endpoint for object-store not found - have you specified a region? Can anyone help me on this issue ? And I referred the below link: http://docs.openstack.org/developer/swift/overview_auth.html Thanks and Regards, Sowmya Nethi sowmya_ne...@persistent.co.inmailto:sowmya_ne...@persistent.co.in | Tel: +91(40)674 42026 Persistent Systems Ltd. | Partners in Innovation | www.persistentsys.comhttp://www.persistentsys.com/ DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Nova Live Migration issue
Thanks Nikolay and Parthipan I have confirmed that the instance is running on the newer compute node by using sudo virsh list command. I'm using below libvirt version .. libvirtd (libvirt) 0.9.8 Actually I will not be able to present the libvirt logs due to setup problem.I'll send logs as soon as possible. Please let me know if any thing needs to be taken care in libvirt during the configuration On Wed, Apr 2, 2014 at 3:00 PM, Parthipan, Loganathan parthi...@hp.comwrote: Can you confirm that it's no longer running on the source node and only running on the destination node? What's your libvirt version? Possibly the libvirt monitor lost connection and didn't complete the post-migration which would update the db. As Nikolay suggested, the libvirt.log would tell more, good if it also had debug turned on. *From:* Nikolay Starodubtsev [mailto:nstarodubt...@mirantis.com] *Sent:* 02 April 2014 09:01 *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] Nova Live Migration issue Hi! Can you show libvirt logs? Nikolay Starodubtsev Software Engineer Mirantis Inc. Skype: dark_harlequine1 2014-04-02 11:55 GMT+04:00 abhishek jain ashujain9...@gmail.com: Hi all I'm following the below link for VM migration from one compute node to the another from the controller node using devstack .. http://www.mirantis.com/blog/tutorial-openstack-live-migration-with-kvm-hypervisor-and-nfs-shared-storage/ I'm able to migrate the instance from one compute node to the other compute node using the below command. nova live-migration b33b23f8-4510-4ed3-8cd1-2d68c8186e40 salaria1 The instance is able to migrate properly and that i have confirmed using the sudo virsh list command over the newer compute node. However the problem is when i type nova list at the same time.The status of instance is stuck at migrating and does not changes even after some time. Moreover when i type nova show instance -id command,the old host of the instance is reflected instead of the new one. Please help regarding this. Thanks Abhishek Jain ___ 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] Nova Live Migration issue
Hello Abhishek, Did you check on the source node whether the instance is still running or even defined (virsh list -all). This is because nova notices that the migration is completed when the VM in the source is gone and then triggers the post-migration. IIRC, there's a bug in 0.x libvirt where the destination qemu disconnection is not picked up by the source libvirt, causing nova migration thread to wait. I don't know if libvirt 1.x works with nova properly yet. Cheers ~parthi From: abhishek jain [mailto:ashujain9...@gmail.com] Sent: 02 April 2014 12:28 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Nova Live Migration issue Thanks Nikolay and Parthipan I have confirmed that the instance is running on the newer compute node by using sudo virsh list command. I'm using below libvirt version .. libvirtd (libvirt) 0.9.8 Actually I will not be able to present the libvirt logs due to setup problem.I'll send logs as soon as possible. Please let me know if any thing needs to be taken care in libvirt during the configuration On Wed, Apr 2, 2014 at 3:00 PM, Parthipan, Loganathan parthi...@hp.commailto:parthi...@hp.com wrote: Can you confirm that it's no longer running on the source node and only running on the destination node? What's your libvirt version? Possibly the libvirt monitor lost connection and didn't complete the post-migration which would update the db. As Nikolay suggested, the libvirt.log would tell more, good if it also had debug turned on. From: Nikolay Starodubtsev [mailto:nstarodubt...@mirantis.commailto:nstarodubt...@mirantis.com] Sent: 02 April 2014 09:01 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Nova Live Migration issue Hi! Can you show libvirt logs? Nikolay Starodubtsev Software Engineer Mirantis Inc. Skype: dark_harlequine1 2014-04-02 11:55 GMT+04:00 abhishek jain ashujain9...@gmail.commailto:ashujain9...@gmail.com: Hi all I'm following the below link for VM migration from one compute node to the another from the controller node using devstack .. http://www.mirantis.com/blog/tutorial-openstack-live-migration-with-kvm-hypervisor-and-nfs-shared-storage/ I'm able to migrate the instance from one compute node to the other compute node using the below command. nova live-migration b33b23f8-4510-4ed3-8cd1-2d68c8186e40 salaria1 The instance is able to migrate properly and that i have confirmed using the sudo virsh list command over the newer compute node. However the problem is when i type nova list at the same time.The status of instance is stuck at migrating and does not changes even after some time. Moreover when i type nova show instance -id command,the old host of the instance is reflected instead of the new one. Please help regarding this. Thanks Abhishek Jain ___ 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-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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] Nova Live Migration issue
Hi Parthi I have confirmed on the destination node i.e( newer compute node on which the instance is migrated ) by using sudo virsh list and the instance is being reflected there. Moreover on the source node the sudo virsh list command reflects nothing. Also I'll try with libvirt 1.x and let you know the result. I'll also try to send you the libvirt logs whenever i try the setup again. Thanks On Wed, Apr 2, 2014 at 5:14 PM, Parthipan, Loganathan parthi...@hp.comwrote: Hello Abhishek, Did you check on the source node whether the instance is still running or even defined (virsh list -all). This is because nova notices that the migration is completed when the VM in the source is gone and then triggers the post-migration. IIRC, there's a bug in 0.x libvirt where the destination qemu disconnection is not picked up by the source libvirt, causing nova migration thread to wait. I don't know if libvirt 1.x works with nova properly yet. Cheers ~parthi *From:* abhishek jain [mailto:ashujain9...@gmail.com] *Sent:* 02 April 2014 12:28 *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] Nova Live Migration issue Thanks Nikolay and Parthipan I have confirmed that the instance is running on the newer compute node by using sudo virsh list command. I'm using below libvirt version .. libvirtd (libvirt) 0.9.8 Actually I will not be able to present the libvirt logs due to setup problem.I'll send logs as soon as possible. Please let me know if any thing needs to be taken care in libvirt during the configuration On Wed, Apr 2, 2014 at 3:00 PM, Parthipan, Loganathan parthi...@hp.com wrote: Can you confirm that it's no longer running on the source node and only running on the destination node? What's your libvirt version? Possibly the libvirt monitor lost connection and didn't complete the post-migration which would update the db. As Nikolay suggested, the libvirt.log would tell more, good if it also had debug turned on. *From:* Nikolay Starodubtsev [mailto:nstarodubt...@mirantis.com] *Sent:* 02 April 2014 09:01 *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] Nova Live Migration issue Hi! Can you show libvirt logs? Nikolay Starodubtsev Software Engineer Mirantis Inc. Skype: dark_harlequine1 2014-04-02 11:55 GMT+04:00 abhishek jain ashujain9...@gmail.com: Hi all I'm following the below link for VM migration from one compute node to the another from the controller node using devstack .. http://www.mirantis.com/blog/tutorial-openstack-live-migration-with-kvm-hypervisor-and-nfs-shared-storage/ I'm able to migrate the instance from one compute node to the other compute node using the below command. nova live-migration b33b23f8-4510-4ed3-8cd1-2d68c8186e40 salaria1 The instance is able to migrate properly and that i have confirmed using the sudo virsh list command over the newer compute node. However the problem is when i type nova list at the same time.The status of instance is stuck at migrating and does not changes even after some time. Moreover when i type nova show instance -id command,the old host of the instance is reflected instead of the new one. Please help regarding this. Thanks Abhishek Jain ___ 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] Keystone PTL Candidacy
Hello, everyone! I'd like to keep my name in the hat as PTL for Keystone during the Juno release cycle. As I'm not looking to shake things up for Juno, I'm going to direct you to my Icehouse PTL candidacy email [1], and promise that I will continue to deliver on that philosophy in Juno. Specifically, it's worth reiterating that my primary focus is in ... supporting our outstanding community of contributors in any way that I can so that they can be as productive as possible. Never mind the PTL, Keystone's success would not be possible without the community behind it. I actually view the client-side pieces to be the most important parts of keystone (and keystoneclient.middleware.auth_token, in particular) due to the more immediate impact on our stakeholders. In terms of Juno, I'm especially looking forward to landing support for ephemeral, signed tokens backed by revocation events on the client-side, along with increasing adoption for keystoneclient.session (and therefore the v3 API) across OpenStack. To all of our contributors during Icehouse: THANK YOU! -Dolph [1] http://lists.openstack.org/pipermail/openstack-dev/2013-September/015387.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Keystone PTL Candidacy
confirmed On 04/02/2014 02:48 PM, Dolph Mathews wrote: Hello, everyone! I'd like to keep my name in the hat as PTL for Keystone during the Juno release cycle. As I'm not looking to shake things up for Juno, I'm going to direct you to my Icehouse PTL candidacy email [1], and promise that I will continue to deliver on that philosophy in Juno. Specifically, it's worth reiterating that my primary focus is in ... supporting our outstanding community of contributors in any way that I can so that they can be as productive as possible. Never mind the PTL, Keystone's success would not be possible without the community behind it. I actually view the client-side pieces to be the most important parts of keystone (and keystoneclient.middleware.auth_token, in particular) due to the more immediate impact on our stakeholders. In terms of Juno, I'm especially looking forward to landing support for ephemeral, signed tokens backed by revocation events on the client-side, along with increasing adoption for keystoneclient.session (and therefore the v3 API) across OpenStack. To all of our contributors during Icehouse: THANK YOU! -Dolph [1] http://lists.openstack.org/pipermail/openstack-dev/2013-September/015387.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tempest][scenario] independece test between Stack and backing services?
Hi Sean, I'm already working on something similar. What I'm trying to do is not a service, but a set of tests that would be able to run commands on the nodes and restart services, kill disks, etc. The basic idea is to inject some fault, see if everything still works as expected and restore the state back to what it was before the fault. So far I only have some basic tests for Swift, but I'm planning more. The state restoration is going to be via snapshots (so it will have to be running in VMs, or I could add support for LVM snapshots too) . The project is called DestroyStack and is located here: https://github.com/mkollaro/destroystack/tree/devel It's still WIP, please don't try to run it yet, not everything is implemented. I'm currently trying to create that demo. Martina On Wed 02 Apr 2014 12:34:43 PM CEST, Sean Dague wrote: Fault injection is a problem I've been thinking about, though I don't have time to dive into it any time soon. But I'll share my ideas in case they are interesting. I think we need a Fault Injection Service for OpenStack. It would act like many of the other OpenStack services, have an API service, and a worker on every node. It would be our own kind of chaos monkey, except very programmable. It would look like any multi host service, communicating over RPC between API and the nodes. The Fault injection service would have the ability to kill process on the hosts (libvirt, nova-compute, c-vol). It would also have the ability to delete did data (simulating a hardware fault). We could definitely use something like this to also signal a service restart, or some other behind the scenes action that we'd expect would be regularly happening. If we had a Fault Injection service, then we could have a class of tests (possibly in Tempest, possibly in another place) which would start resources with the OpenStack API, then inject faults, then continue along the way. I feel like Juno is too soon for this, as we have lots of other issues to address. However, K might work. That being said, if anyone wants to dive in early, have at. The important thing would be that this has REST API, and that it be multi node. -Sean On 04/02/2014 04:37 AM, Tomoya Goto wrote: Hello, Igawa-san Thanks for pointing out Tempest principles. I wasn't aware of them. ok, I'll probably use the current test cases with manually stopping services. I'm checking with Temest(icehouse) and if I write or think up something useful, I'll be back. Also Grenade, too. :) Thank you for valuable advices, - Tomoya Goto Hi, On 04/02, Tomoya Goto wrote: Thanks for quick replies Igawa-san and Mr.Sean! :) and sorry foy my slow reply :( np :) The task I wantetd to conduct is not only for upgrading but also for rather small maintenace, say stopping openstack-cinder* for changing configuration. Now, Grenade is for upgrade purpose but not for such small maintenace, right? So I think tempest is more suitable than Grenade for such task. what do you say? This kind (fault injection?) of tests that you said are interesting and we should have them in future. But Tempest should not operate OpenStack components directly. e.g. stop/start Cinder/Glance/Nova services. This is one of design principles[1]. So I think we need a new project for these types of tests or need to change the principles. [1] http://docs.openstack.org/developer/tempest/overview.html#design-principles Thanks, -- Masayuki Igawa - Tomoya Goto You are correct. The testing we do for this is in Grenade, which we run in the gate. Grenade tests an upgrade from last stable release to current master. It creates a few resources before the upgrade, and fails if those are interupted after the upgrade. Grenade is still pretty light on the number of resources it creates before the upgrade, and is definitely a place where enhancement is welcome. -Sean On 04/01/2014 04:18 AM, Masayuki Igawa wrote: Hi Goto-san, I think this is an interesting test case. But AFAIK, Tempest and its scenario tests don't have such test cases now, and we can't stop the OpenStack processes through Tempest. Do you know Grenade[1]? I think Grenade is the only one upgrading test in the OpenStack community now. So I guess Grenade can test these kind of tests but not yet though. [1] https://wiki.openstack.org/wiki/Grenade On 04/01, 後藤 僚哉 wrote: Hello everyone. I'm looking for an independence test between an OpenStack environment and virtual environments. In case of updating an openstack environment, you need to stop each OpenStack process, but you don't want the instances to be affected by OpenStack outages. So before maintenane, you want to make sure OpenStack and backing services(KVM, OVS, storage,.) are separate. For example. 1) Creating a virtual environment on a OpenStack environment. this includes Nova instances, Neutron L2/3 networks, Cinder volumes and etc. I'd like to clarify more. Do you mean OpenStack on OpenStack environment?
Re: [openstack-dev] [Keystone] python-keystoneclient v3 functionality
On 04/01/2014 07:36 AM, Yaguang Tang wrote: Thanks Jamie, then the following question is do we intend to move other services client library V3 identity support to python-openstackclient? AFAIK it's poorly supported for Nova Cinder Neutron client library, and I am working on add v3 support for those libraries[1], just want to make sure that is the correct direction. [1] https://review.openstack.org/#/c/81749/ https://review.openstack.org/#/c/81767/ Sort of. The Keystone client should be responsible for all fo the service catalog manipulations throughout openstack. So the Cinder client should use the Keystone client. To see the idea, read Jamie's blog post: http://www.jamielennox.net/blog/2014/02/24/client-session-objects/ The main idea is that Keystone will handle the HTTP session setup, so that we have a single place to focus attention on for HTTP network security issues. And you should not need to parse the service catalog at all. 2014-04-01 12:08 GMT+08:00 Jamie Lennox jamielen...@redhat.com mailto:jamielen...@redhat.com: On Tue, 2014-04-01 at 11:53 +0800, Yaguang Tang wrote: Hi all, I am sorry if this has been discussed before, the question is will we support keystone v3 operation in python-keystoneclient? I know most of the v3 functionality have been implemented in python-openstackclient, but from the python-openstackclient wiki says, it's primarily a wrapper of python-*client, and provides unified interface to user. The end user uses python-keystoneclient to manage user, tenant, service before, if we don't intend to support v3 functionality in keystoneclient, then it means we force end user to change from keystoneclient to openstackclient, is this what we want to do? It depends what you mean by python-keystoneclient. If you mean the python library then yes it supports the V3 API already. If you mean the keystone CLI that is currently bundled as part of the python-keystoneclient then yes that is deprecated in favour of python-openstackclient. We will maintain the CLI application in keystoneclient however even for V2 API calls I recommend that you use the openstack CLI tool. Jamie -- Tang Yaguang Canonical Ltd. | www.ubuntu.com http://www.ubuntu.com | www.canonical.com http://www.canonical.com Mobile: +86 152 1094 6968 tel:%2B86%20152%201094%206968 gpg key: 0x187F664F ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Tang Yaguang Canonical Ltd. | www.ubuntu.com http://www.ubuntu.com/ | www.canonical.com http://www.canonical.com/ Mobile: +86 152 1094 6968 gpg key: 0x187F664F ___ 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] [All][Keystone] Deprecation of the v2 API
On Tue, Apr 1, 2014 at 7:40 PM, Anne Gentle a...@openstack.org wrote: On Wed, Mar 26, 2014 at 5:30 AM, Thierry Carrez thie...@openstack.orgwrote: Russell Bryant wrote: [...] First, it seems there isn't a common use of deprecated. To me, marking something deprecated means that the deprecated feature: - has been completely replaced by something else - end users / deployers should take action to migrate to the new thing immediately. - The project has provided a documented migration path - the old thing will be removed at a specific date/release Agreed, IMHO we need to reserve the use the deprecated terminology for the idea of moving end users, deployers, external client library developers (people outside of OpenStack direct reach) off a given API version. Deprecation is about giving them a fair heads-up about something that is about to be removed, so that they are encouraged to move off it. It needs to be discussed and announced with the user community, and come with a precise plan. Internal consumption of APIs between OpenStack projects is a different beast: (1) it's under our control and (2) we really can't remove an API until all our internal pieces have migrated off it. So I wouldn't use deprecation warnings to encourage other OpenStack projects to move off an API. They can't come with a precise date since if projects don't comply with this suggestion we just can't remove that API support. I would therefore go this way: 1. API vN is stable and supported 2. API vN+1 is being developed and experimental 3. API vN+1 is marked stable and supported 4. Engage with other consuming OpenStack projects to migrate to vN+1 5. Migration is completed 6. Deprecation plan (and removal date) is discussed with stakeholders 7. Deprecation plan (and removal date) is decided and announced 8. Deprecation messages are added to code for API vN users 9. At removal date, API vN is removed Keystone is at step 4. It shouldn't use deprecation terminology before step 6. Hi all, I wanted to double-check some wording. I'm chasing down how to update docs based on a DocImpact flag[1] with related bugs and the nova blueprint to deprecate XML. [2] I'm pretty sure deprecate is the term we're using as the message says XML support has been deprecated and will be removed in the Juno release. [3] I don't see any issue with using the term deprecate here. However, I think it's important to say it may be removed, not will. Deprecations are frequently delayed, so the wording has potential to be inaccurate as-is. You could even go so far as to say it *may* be removed *as early as* the Juno release. Oslo's deprecation decorator (the deprecator) does not use the wording today, though. To me, the same arguments that caused a different message to be substituted for Keystone's v2.0 API could be used here. Is that inaccurate? Has the discussion been carried to the logical conclusion? Should deprecated be used yet? I just want to point out that Keystone followed Nova's lead on this one - Keystone's XML support, which is only rigorously tested against a very small portion of the v2 API, is deprecated as of Icehouse as well. I think XML is a broader community issue, not one that needs to be discussed per-project. I think we could follow a similar pattern for XML in the Compute API v2 -- we need to define discussed with stakeholders and how/when we say the discussion is done. I wanted to put up a set of ideas for the channels (push) and inputs (pull): - posted a collaborative statement expressing need to deprecate to the openstack-dev mailing list - posted a request for comment to the openstack mailing list In the case of XML, I think we already have a sufficiently long history of relevant mailing list discussions suggesting a focus on a single serialization format (JSON, in our case). - questions added to the user survey that indicate amount of use and desire to move away from - responses to user survey compiled showing a certain percent of agreement on deprecation This would be really interesting to see, at least for XML. I wouldn't recommend it for all the smaller features that face deprecation each release. Would that be sufficient for the discussed with stakeholders step? Any other channels I'm missing? If the discussion requires six months of discussion at a minimum, is that acceptable? One of keystone's summit sessions in Hong Kong partly focused on producing a list of things to deprecate during Icehouse. We ended up deprecating things that there was a clear consensus on (redundant middleware, etc). Although there were certainly deployers represented in that session, I like the idea of making deprecations a regular topic in a project-specific design session focused on collecting deployer feedback (using the session format suggested in a recent openstack-dev thread for Atlanta). Thanks, Anne [1]
Re: [openstack-dev] Operators Design Summit ideas for Atlanta
On Mon, Mar 31, 2014 at 10:40 PM, Adam Young ayo...@redhat.com wrote: On 03/28/2014 03:01 AM, Tom Fifield wrote: Thanks to those projects that responded. I've proposed sessions in swift, ceilometer, tripleO and horizon. Keystone would also be interested in user feedback, of course. Crossing openstack-dev threads [1] here, gathering feedback on proposed deprecations would be a great topic for such a session. [1] http://lists.openstack.org/pipermail/openstack-dev/2014-April/031652.html On 17/03/14 07:54, Tom Fifield wrote: All, Many times we've heard a desire for more feedback and interaction from users. However, their attendance at design summit sessions is met with varied success. However, last summit, by happy accident, a swift session turned into a something a lot more user driven. A competent user was able to describe their use case, and the developers were able to stage a number of question to them. In this way, some of the assumptions about the way certain things were implemented, and the various priorities of future plans became clearer. It worked really well ... perhaps this is something we'd like to have happen for all the projects? *Idea*: Add an ops session for each project in the design summit https://etherpad.openstack.org/p/ATL-ops-dedicated- design-summit-sessions Most operators running OpenStack tend to treat it more holistically than those coding it. They are aware of, but don't necessarily think or work in terms of project breakdowns. To this end, I'd imagine the such sessions would: * have a primary purpose for developers to ask the operators to answer questions, and request information * allow operators to tell the developers things (give feedback) as a secondary purpose that could potentially be covered better in a cross-project session * need good moderation, for example to push operator-to-operator discussion into forums with more time available (eg https://etherpad.openstack.org/p/ATL-ops-unconference-RFC ) * be reinforced by having volunteer good users in potentially every design summit session (https://etherpad.openstack.org/p/ATL-ops-in-design-sessions ) Anyway, just a strawman - please jump on the etherpad (https://etherpad.openstack.org/p/ATL-ops-dedicated- design-summit-sessions) or leave your replies here! Regards, Tom ___ 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] [Tuskar][Horizon] Javascript linter
On 02/04/14 15:26, Kevin Conway wrote: What licensing issues were brought up that prevent the use of JSLint or JSHint? Both are MIT licensed. Granted, JSLint has an additional clause: The Software shall be used for Good, not Evil. Maybe that's it? If so, Crockford has been known to make exceptions for organizations that wish to use his code for potentially evil purposes: https://www.youtube.com/watch?v=-C-JoyNuQJsfeature=player_detailpage#t=2480s. Yes, that's exactly it. An exception is not enough -- that clause simply makes that license incompatible with OpenStack's license. To use it, we would need to change OpenStack's license too, and it quickly becomes quite complex. You have to remember that organizations like NSA use OpenStack, so we can't possibly include that clause in its license ;) -- Radomir Dopieralski ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tempest][scenario] independece test between Stack and backing services?
Good stuff. I like the semantics of what the destroy stack tests look like, very clean. I still think there would be value in doing this as a API service, which would let you decouple the test cases (and even put them in Tempest), as the tests could just assume certain fault semantics, and the implementation (which could even start with the ssh to nodes approach) would be left to the fault service. Do you think this would be an interesting evolution of destroystack, or is that different enough in goals that we should think about this problem separately. -Sean On 04/02/2014 08:55 AM, Martina Kollarova wrote: Hi Sean, I'm already working on something similar. What I'm trying to do is not a service, but a set of tests that would be able to run commands on the nodes and restart services, kill disks, etc. The basic idea is to inject some fault, see if everything still works as expected and restore the state back to what it was before the fault. So far I only have some basic tests for Swift, but I'm planning more. The state restoration is going to be via snapshots (so it will have to be running in VMs, or I could add support for LVM snapshots too) . The project is called DestroyStack and is located here: https://github.com/mkollaro/destroystack/tree/devel It's still WIP, please don't try to run it yet, not everything is implemented. I'm currently trying to create that demo. Martina On Wed 02 Apr 2014 12:34:43 PM CEST, Sean Dague wrote: Fault injection is a problem I've been thinking about, though I don't have time to dive into it any time soon. But I'll share my ideas in case they are interesting. I think we need a Fault Injection Service for OpenStack. It would act like many of the other OpenStack services, have an API service, and a worker on every node. It would be our own kind of chaos monkey, except very programmable. It would look like any multi host service, communicating over RPC between API and the nodes. The Fault injection service would have the ability to kill process on the hosts (libvirt, nova-compute, c-vol). It would also have the ability to delete did data (simulating a hardware fault). We could definitely use something like this to also signal a service restart, or some other behind the scenes action that we'd expect would be regularly happening. If we had a Fault Injection service, then we could have a class of tests (possibly in Tempest, possibly in another place) which would start resources with the OpenStack API, then inject faults, then continue along the way. I feel like Juno is too soon for this, as we have lots of other issues to address. However, K might work. That being said, if anyone wants to dive in early, have at. The important thing would be that this has REST API, and that it be multi node. -Sean On 04/02/2014 04:37 AM, Tomoya Goto wrote: Hello, Igawa-san Thanks for pointing out Tempest principles. I wasn't aware of them. ok, I'll probably use the current test cases with manually stopping services. I'm checking with Temest(icehouse) and if I write or think up something useful, I'll be back. Also Grenade, too. :) Thank you for valuable advices, - Tomoya Goto Hi, On 04/02, Tomoya Goto wrote: Thanks for quick replies Igawa-san and Mr.Sean! :) and sorry foy my slow reply :( np :) The task I wantetd to conduct is not only for upgrading but also for rather small maintenace, say stopping openstack-cinder* for changing configuration. Now, Grenade is for upgrade purpose but not for such small maintenace, right? So I think tempest is more suitable than Grenade for such task. what do you say? This kind (fault injection?) of tests that you said are interesting and we should have them in future. But Tempest should not operate OpenStack components directly. e.g. stop/start Cinder/Glance/Nova services. This is one of design principles[1]. So I think we need a new project for these types of tests or need to change the principles. [1] http://docs.openstack.org/developer/tempest/overview.html#design-principles Thanks, -- Masayuki Igawa - Tomoya Goto You are correct. The testing we do for this is in Grenade, which we run in the gate. Grenade tests an upgrade from last stable release to current master. It creates a few resources before the upgrade, and fails if those are interupted after the upgrade. Grenade is still pretty light on the number of resources it creates before the upgrade, and is definitely a place where enhancement is welcome. -Sean On 04/01/2014 04:18 AM, Masayuki Igawa wrote: Hi Goto-san, I think this is an interesting test case. But AFAIK, Tempest and its scenario tests don't have such test cases now, and we can't stop the OpenStack processes through Tempest. Do you know Grenade[1]? I think Grenade is the only one upgrading test in the OpenStack community now. So I guess Grenade can test these kind of tests but
[openstack-dev] [sahara] team meeting April 3 1800 UTC [savanna]
Hi folks, We'll be having the Sahara team meeting as usual in #openstack-meeting-alt channel. Agenda: https://wiki.openstack.org/wiki/Meetings/SaharaAgenda#Agenda_for_April.2C_3 http://www.timeanddate.com/worldclock/fixedtime.html?msg=Sahara+Meetingiso=20140403T18 -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tempest][scenario] independece test between Stack and backing services?
On Wed 02 Apr 2014 03:38:18 PM CEST, Sean Dague wrote: Good stuff. I like the semantics of what the destroy stack tests look like, very clean. I still think there would be value in doing this as a API service, which would let you decouple the test cases (and even put them in Tempest), as the tests could just assume certain fault semantics, and the implementation (which could even start with the ssh to nodes approach) would be left to the fault service. This would still leave some problems that would make it difficult to add these tests into Tempest. First, to check if if some things are working beyond some basic yep, it sent back 200, you need access to the nodes. For example, when I'm testing Swift, I check if there are 3 replicas of each object by looking into the internals a bit - there is no API for this and I wouldn't trust it even if there was. Another problem would be test isolation - how would you do test clean-up in Tempest if you don't have access to the servers and cannot even start up a service? You would need a full OpenStack management service (could TripleO somehow do this?). But it would be interesting...the first implementation of Daas - Destruction as a Service. Martina Do you think this would be an interesting evolution of destroystack, or is that different enough in goals that we should think about this problem separately. -Sean On 04/02/2014 08:55 AM, Martina Kollarova wrote: Hi Sean, I'm already working on something similar. What I'm trying to do is not a service, but a set of tests that would be able to run commands on the nodes and restart services, kill disks, etc. The basic idea is to inject some fault, see if everything still works as expected and restore the state back to what it was before the fault. So far I only have some basic tests for Swift, but I'm planning more. The state restoration is going to be via snapshots (so it will have to be running in VMs, or I could add support for LVM snapshots too) . The project is called DestroyStack and is located here: https://github.com/mkollaro/destroystack/tree/devel It's still WIP, please don't try to run it yet, not everything is implemented. I'm currently trying to create that demo. Martina On Wed 02 Apr 2014 12:34:43 PM CEST, Sean Dague wrote: Fault injection is a problem I've been thinking about, though I don't have time to dive into it any time soon. But I'll share my ideas in case they are interesting. I think we need a Fault Injection Service for OpenStack. It would act like many of the other OpenStack services, have an API service, and a worker on every node. It would be our own kind of chaos monkey, except very programmable. It would look like any multi host service, communicating over RPC between API and the nodes. The Fault injection service would have the ability to kill process on the hosts (libvirt, nova-compute, c-vol). It would also have the ability to delete did data (simulating a hardware fault). We could definitely use something like this to also signal a service restart, or some other behind the scenes action that we'd expect would be regularly happening. If we had a Fault Injection service, then we could have a class of tests (possibly in Tempest, possibly in another place) which would start resources with the OpenStack API, then inject faults, then continue along the way. I feel like Juno is too soon for this, as we have lots of other issues to address. However, K might work. That being said, if anyone wants to dive in early, have at. The important thing would be that this has REST API, and that it be multi node. -Sean On 04/02/2014 04:37 AM, Tomoya Goto wrote: Hello, Igawa-san Thanks for pointing out Tempest principles. I wasn't aware of them. ok, I'll probably use the current test cases with manually stopping services. I'm checking with Temest(icehouse) and if I write or think up something useful, I'll be back. Also Grenade, too. :) Thank you for valuable advices, - Tomoya Goto Hi, On 04/02, Tomoya Goto wrote: Thanks for quick replies Igawa-san and Mr.Sean! :) and sorry foy my slow reply :( np :) The task I wantetd to conduct is not only for upgrading but also for rather small maintenace, say stopping openstack-cinder* for changing configuration. Now, Grenade is for upgrade purpose but not for such small maintenace, right? So I think tempest is more suitable than Grenade for such task. what do you say? This kind (fault injection?) of tests that you said are interesting and we should have them in future. But Tempest should not operate OpenStack components directly. e.g. stop/start Cinder/Glance/Nova services. This is one of design principles[1]. So I think we need a new project for these types of tests or need to change the principles. [1] http://docs.openstack.org/developer/tempest/overview.html#design-principles Thanks, -- Masayuki Igawa - Tomoya Goto You are correct. The testing we do for this is in Grenade,
Re: [openstack-dev] [Tuskar][Horizon] Javascript linter
I understand, and appreciate, the concern for licensing, but it would be a real shame to discount some of the most widely used linters because of a clause that prevents us from being evil. Any chance we could run this by legal-disc...@lists.openstack.org and hear their reactions before we axe the JS*int projects from OpenStack? On 4/2/14 8:43 AM, Radomir Dopieralski openst...@sheep.art.pl wrote: On 02/04/14 15:26, Kevin Conway wrote: What licensing issues were brought up that prevent the use of JSLint or JSHint? Both are MIT licensed. Granted, JSLint has an additional clause: The Software shall be used for Good, not Evil. Maybe that's it? If so, Crockford has been known to make exceptions for organizations that wish to use his code for potentially evil purposes: https://www.youtube.com/watch?v=-C-JoyNuQJsfeature=player_detailpage#t=2 480s. Yes, that's exactly it. An exception is not enough -- that clause simply makes that license incompatible with OpenStack's license. To use it, we would need to change OpenStack's license too, and it quickly becomes quite complex. You have to remember that organizations like NSA use OpenStack, so we can't possibly include that clause in its license ;) -- Radomir Dopieralski ___ 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] [All][Keystone] Deprecation of the v2 API
On Wed, Apr 2, 2014 at 8:43 AM, Russell Bryant rbry...@redhat.com wrote: On 04/02/2014 09:20 AM, Dolph Mathews wrote: On Tue, Apr 1, 2014 at 7:40 PM, Anne Gentle a...@openstack.org mailto:a...@openstack.org wrote: On Wed, Mar 26, 2014 at 5:30 AM, Thierry Carrez thie...@openstack.org mailto:thie...@openstack.org wrote: Russell Bryant wrote: [...] First, it seems there isn't a common use of deprecated. To me, marking something deprecated means that the deprecated feature: - has been completely replaced by something else - end users / deployers should take action to migrate to the new thing immediately. - The project has provided a documented migration path - the old thing will be removed at a specific date/release Agreed, IMHO we need to reserve the use the deprecated terminology for the idea of moving end users, deployers, external client library developers (people outside of OpenStack direct reach) off a given API version. Deprecation is about giving them a fair heads-up about something that is about to be removed, so that they are encouraged to move off it. It needs to be discussed and announced with the user community, and come with a precise plan. Internal consumption of APIs between OpenStack projects is a different beast: (1) it's under our control and (2) we really can't remove an API until all our internal pieces have migrated off it. So I wouldn't use deprecation warnings to encourage other OpenStack projects to move off an API. They can't come with a precise date since if projects don't comply with this suggestion we just can't remove that API support. I would therefore go this way: 1. API vN is stable and supported 2. API vN+1 is being developed and experimental 3. API vN+1 is marked stable and supported 4. Engage with other consuming OpenStack projects to migrate to vN+1 5. Migration is completed 6. Deprecation plan (and removal date) is discussed with stakeholders 7. Deprecation plan (and removal date) is decided and announced 8. Deprecation messages are added to code for API vN users 9. At removal date, API vN is removed Keystone is at step 4. It shouldn't use deprecation terminology before step 6. Hi all, I wanted to double-check some wording. I'm chasing down how to update docs based on a DocImpact flag[1] with related bugs and the nova blueprint to deprecate XML. [2] I'm pretty sure deprecate is the term we're using as the message says XML support has been deprecated and will be removed in the Juno release. [3] I don't see any issue with using the term deprecate here. However, I think it's important to say it may be removed, not will. Deprecations are frequently delayed, so the wording has potential to be inaccurate as-is. You could even go so far as to say it *may* be removed *as early as* the Juno release. Oslo's deprecation decorator (the deprecator) does not use the wording today, though. Agree that the wording should be changed. https://review.openstack.org/84725 https://bugs.launchpad.net/nova/+bug/1301384 I'll get this into icehouse-rc2 for Nova. To me, the same arguments that caused a different message to be substituted for Keystone's v2.0 API could be used here. Is that inaccurate? Has the discussion been carried to the logical conclusion? Should deprecated be used yet? I just want to point out that Keystone followed Nova's lead on this one - Keystone's XML support, which is only rigorously tested against a very small portion of the v2 API, is deprecated as of Icehouse as well. I think XML is a broader community issue, not one that needs to be discussed per-project. In terms of the the project-wide issue, the TC at least formalized that the only thing we expect from a project is a REST API with JSON support. We didn't want to *prevent* XML support. http://git.openstack.org/cgit/openstack/governance/tree/reference/incubation-integration-requirements#n40 Project must have a REST API with at least a JSON entity representation I think we could follow a similar pattern for XML in the Compute API v2 -- we need to define discussed with stakeholders and how/when we say the discussion is done. I wanted to put up a set of ideas for the channels (push) and inputs (pull): - posted a collaborative statement expressing need to deprecate to the openstack-dev mailing list - posted a request for comment to the
Re: [openstack-dev] [Ceilometer] Collector no recheck the db status
I found that when collector service starting, if the db has not yet ready, it will log an error info like 'Could not load 'database': could not connect to...' but the service still goes on. Later when the db is ready, but there are no mechanisms to check the db status and reconnect it. so the collector service keeps useless to record the data. is this against master? does this patch resolve the issue for you? https://review.openstack.org/#/c/83595/ gordon chung openstack, ibm software standards___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Missleading and hardly parseable default neutron config files
IMHO, having Example: on a separate line from the actual option is a lot easier for humans: you just delete a single character or use your editor-of-choice's uncomment macro to activate a line. - Original Message - From: Russell Bryant rbry...@redhat.com To: openstack-dev@lists.openstack.org Sent: Wednesday, April 2, 2014 9:45:05 AM Subject: Re: [openstack-dev] Missleading and hardly parseable default neutron config files On 04/02/2014 06:38 AM, Salvatore Orlando wrote: Hi Thomas, it probably won't be a bad idea if you can share the patches you're applying to the default configuration files. I think all distros are patching them anyway, so this might allow us to provide mostly ready to use config files. Is there a chance you can push something to gerrit? How about auto generate the sample config like most other projects? -- Russell Bryant ___ 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] [OSSG][OSSN] Potential token revocation abuse via group membership
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Potential token revocation abuse via group membership - --- ### Summary ### Deletion of groups in Keystone causes token revocation for group members. If group capabilities are delegated to users, they can abuse those capabilities to maliciously revoke tokens for other users. ### Affected Services / Software ### Keystone, Grizzly, Havana, Icehouse ### Discussion ### If a group is deleted from Keystone, all tokens for all users that are members of that group are revoked. By adding users to a group without those users' knowledge and then deleting that group, a group admin can revoke all of the users' tokens. While the default policy file gives the group admin role to global admin, an alternative policy could delegate the create_group, add_user_to_group, and delete_group capabilities to a set of users. In such a system, those users will also get a token revocation capability. Only setups using a custom policy file in Keystone are affected. ### Recommended Actions ### Keystone's default policy.json file uses the admin_required rule for the create_group, delete_group, and add_user_to_group capabilities. It is recommended that you use this default configuration if possible. Here is an example snippet of a properly configured policy.json file: - begin example policy.json snippet identity:create_group: rule:admin_required, identity:delete_group: rule:admin_required, identity:add_user_to_group: rule:admin_required, - end example policy.json snippet If you need to delegate the above capabilities to non-admin users, you need to take into account that those users will be able to revoke tokens for other users by performing group deletion operations. You should take caution with who you delegate these capabilities to. ### Contacts / References ### This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0009 Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1268751 OpenStack Security ML : openstack-secur...@lists.openstack.org OpenStack Security Group : https://launchpad.net/~openstack-ossg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTPCYGAAoJEJa+6E7Ri+EVw+wIAI1RaoIuHf7VAQSI8J/RhUK/ sKmoKUmEq0yDTQwKnbW2X8PMM6t4d4NDV0bSJfrKZYjnIWBNoh0hk3yg4GYytn2s s8o31ctOhWWOx/EGfnhlm7IrJZ91KmnhrVTLMdSFOQhiIzxa2gyEk0Fw3k6oYlDN wJWC5NyKKeNpjb7SSoHhifcQ/7FGUJIcd8tnm1KT3vMrK9pUM46Jsb8sdfZ2+8hE ym3vCSc47t5K/32HFDjiAsfaCKBVIoJeOBOJGOcsQIpuW6GkRB8Ic5n2+EW25Z3O y5tgwhHZaoTL6K0KlpGHPvVSoeJea09yTL97KqCIcMM89KwNcKvobM2KHgtwqHY= =i6VA -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it
Awesome guys! I'll do it! I have the neutron-ipv6.patch that came from the output of git format-patch -1 --stdout FETCH_HEAD but, it did not got applied successfully against neutron-2014.1.rc1, look: --- builder@neutron-dev-1:~/neutron/neutron-2014.1.rc1$ patch -p1 ../ipv6-bits/neutron-shixiong/neutron-ipv6.patch patching file neutron/agent/l3_agent.py Hunk #1 succeeded at 696 (offset 31 lines). Hunk #2 succeeded at 722 (offset 31 lines). patching file neutron/agent/linux/dhcp.py Hunk #2 FAILED at 334. Hunk #3 FAILED at 419. Hunk #4 succeeded at 534 with fuzz 2 (offset 56 lines). Hunk #5 succeeded at 548 (offset 56 lines). Hunk #6 succeeded at 664 (offset 56 lines). 2 out of 6 hunks FAILED -- saving rejects to file neutron/agent/linux/dhcp.py.rej patching file neutron/common/constants.py Hunk #1 succeeded at 113 (offset 1 line). patching file neutron/tests/unit/test_dhcp_agent.py Hunk #2 succeeded at 221 (offset 4 lines). Hunk #3 succeeded at 260 (offset 4 lines). patching file neutron/tests/unit/test_l3_agent.py Hunk #1 succeeded at 145 (offset -1 lines). patching file neutron/tests/unit/test_linux_dhcp.py Hunk #6 succeeded at 578 (offset -1 lines). Hunk #7 succeeded at 595 (offset -1 lines). Hunk #8 succeeded at 666 (offset -1 lines). Hunk #9 FAILED at 740. Hunk #13 FAILED at 1068. Hunk #14 FAILED at 1085. Hunk #15 FAILED at 1110. Hunk #16 FAILED at 1117. Hunk #17 succeeded at 1101 with fuzz 1 (offset -34 lines). Hunk #18 FAILED at 1162. 6 out of 18 hunks FAILED -- saving rejects to file neutron/tests/unit/test_linux_dhcp.py.rej --- It failed and I'm not a coder but, I think I can work on this (it might take days) to build Neutron IPv6 Ubuntu packages for us... Nevertheless, if someone (Shixiong ? :-D ) can update it (to be applied on top of neutron-2014.1.rc1), I think I'll be able to publish the packages on PPA on the next day! - The CLI command may look like, for example, something below: --- neutron subnet-create --ip-version 6 --ipv6_ra_mode off --ipv6_address_mode off NETWORK CIDR neutron subnet-create --ip-version 6 --ipv6_ra_mode off --ipv6_address_mode dhcpv6-stateful NETWORK CIDR neutron subnet-create --ip-version 6 --ipv6_ra_mode slaac --ipv6_address_mode slaac NETWORK CIDR neutron subnet-create --ip-version 6 --ipv6_ra_mode dhcpv6-stateful --ipv6_address_mode off NETWORK CIDR neutron subnet-create --ip-version 6 --ipv6_ra_mode dhcpv6-stateless --ipv6_address_mode dhcpv6-stateless NETWORK CIDR --- References: neutron-ipv6.patch: http://paste.openstack.org/show/74857/ http://lists.openstack.org/pipermail/openstack-dev/2014-February/026589.html http://lists.openstack.org/pipermail/openstack-dev/2014-February/026809.html Cheers! Thiago On 2 April 2014 08:44, Sebastian Herzberg sebastian.herzb...@gmail.comwrote: Hi, from my side there is definite interest in this, as the changes didn't make it yet. Thanks Sebastian ___ 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] [Neutron] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it
On Wed, Apr 02, 2014 at 11:13:32AM EDT, Martinx - ジェームズ wrote: Awesome guys! I'll do it! OK - so keep an eye on: https://review.openstack.org/#/c/70649/ Once it is rebased to solve the merge conflicts, and all the tests pass, then perhaps we can look into any of this backporting or PPA business. So keep your powder dry ;) -- Sean M. Collins ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it
LOL! AWESOME!! No problem... I know that you guys have a lot to do... :-) But, can this current neutron-ipv6.patch at least, be used to enable Neutron IPv6 with RA (--ipv6_ra_mode slaac --ipv6_address_mode slaac) ? Otherwise, is a nutshell, what can be achieved these days with the bleeding edge Neutron IPv6 code?! I'm watching https://review.openstack.org/#/c/70649/ :) Tks Sean! Thiago On 2 April 2014 12:24, Collins, Sean sean_colli...@cable.comcast.comwrote: On Wed, Apr 02, 2014 at 11:13:32AM EDT, Martinx - ジェームズ wrote: Awesome guys! I'll do it! OK - so keep an eye on: https://review.openstack.org/#/c/70649/ Once it is rebased to solve the merge conflicts, and all the tests pass, then perhaps we can look into any of this backporting or PPA business. So keep your powder dry ;) -- Sean M. Collins ___ 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] [Ironic] Icehouse RC1 available
Hello everyone, Ironic published its first Icehouse release candidate yesterday. The list of bugs fixed since feature freeze and the RC1 tarball are available at: https://launchpad.net/ironic/icehouse/icehouse-rc1 Unless release-critical issues are found that warrant a release candidate respin, this RC1 will be formally released as the 2014.1 final version on April 17. You are therefore strongly encouraged to test and validate this tarball. Alternatively, you can directly test the milestone-proposed branch at: https://github.com/openstack/ironic/tree/milestone-proposed If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/ironic/+filebug and tag it *icehouse-rc-potential* to bring it to the release crew's attention. Note that the master branch of Ironic is now open for Juno development, and feature freeze restrictions no longer apply there. Many thanks should be directed to Thierry for his assistance in making the release happen, and for answering my endless stream of questions as I learn [*]. Regards, Devananda [*] and for the excellent announcement template which I have shamelessly copied. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Tuskar][Horizon] Javascript linter
I think that would be a good idea. We're not shipping this, we're just using it in test (AIUI), so I don't think incompatibility with the OpenStack license is necessarily an issue. But IANAL. :-) -Ben On 04/02/2014 09:24 AM, Kevin Conway wrote: I understand, and appreciate, the concern for licensing, but it would be a real shame to discount some of the most widely used linters because of a clause that prevents us from being evil. Any chance we could run this by legal-disc...@lists.openstack.org and hear their reactions before we axe the JS*int projects from OpenStack? On 4/2/14 8:43 AM, Radomir Dopieralski openst...@sheep.art.pl wrote: On 02/04/14 15:26, Kevin Conway wrote: What licensing issues were brought up that prevent the use of JSLint or JSHint? Both are MIT licensed. Granted, JSLint has an additional clause: The Software shall be used for Good, not Evil. Maybe that's it? If so, Crockford has been known to make exceptions for organizations that wish to use his code for potentially evil purposes: https://www.youtube.com/watch?v=-C-JoyNuQJsfeature=player_detailpage#t=2 480s. Yes, that's exactly it. An exception is not enough -- that clause simply makes that license incompatible with OpenStack's license. To use it, we would need to change OpenStack's license too, and it quickly becomes quite complex. You have to remember that organizations like NSA use OpenStack, so we can't possibly include that clause in its license ;) -- Radomir Dopieralski ___ 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] [Murano] MuranoPL = UML visualization - best implementation practices?
So it does, I hadn't realized that. The earlier message mentioned using a command-line tool to produce pretty graph images, and I figured I knew just the tool for the job. Since you're already indirectly using Graphviz, if you're only using PlantUML for processing the output of umlgen.py into a PNG, why not skip a step and generate the Graphviz input file yourself? Granted, it'll take some work to build a similar visual style--I see elaborate record nodes in your future--but you don't have to be bound to PlantUML if you don't want to be. I've used Graphviz before for a few applications, and if I can help get you started with building dot files, let me know. That said, weighing effort against result, you may just be better off sticking with Plant at least in the short term. I'm sorry I can't suggest a simpler alternative for you right now. From: Dmitry Teselkin dtesel...@mirantis.commailto:dtesel...@mirantis.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, April 2, 2014 at 12:05 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Murano] MuranoPL = UML visualization - best implementation practices? Hi, GraphViz is alreary used by Plant UML to produce output PNG file, see 'image generation chain' below: * umlgen.py walks through MuranoPL class(es) and generated temporary file which contains Plant UML definitions for the entire graph * Plant UML is called with that file as input * Plant UML processes input file somehow and uses GraphViz to build output image On Tue, Apr 1, 2014 at 11:25 PM, Ed Cranford ed.cranf...@rackspace.commailto:ed.cranf...@rackspace.com wrote: What about Graphviz? On 4/1/14, 1:34 PM, Timur Sufiev tsuf...@mirantis.commailto:tsuf...@mirantis.com wrote: Hello! Recently we've made an attempt to make MuranoPL class definitions more conceivable for everyone, and decided to use UML diagrams for that purpose. The most obvious (and quick) solution was to use a well-known tool [1], the command-line script which uses it is almost ready [2], and the final result seems quite satisfying to us [3] (pictures are drawn using current version of script). Moreover, we liked these diagrams so much that decided to show them also in Murano's WebUI (right after the uploaded App Package has been validated). But we're little uncertain about using Java-based tool in the long run: it doesn't seem to fit very well with OpenStack common practices. So could you advice some good enough Python and/or Javascript library for generating UML diagrams? The most important criteria is an ability to produce graphics as beautiful as Plant UML does. [1] http://plantuml.sourceforge.net/ [2] https://review.openstack.org/#/c/83348/ [3] https://www.dropbox.com/sh/pesyejyjo624o34/fCe1_OM-OH#lh:null-io.murano.En vironment.png -- Timur Sufiev ___ 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-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks, Dmitry Teselkin Deployment Engineer Mirantis http://www.mirantis.comhttp://www.mirantis.com/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Missleading and hardly parseable default neutron config files
On 04/02/2014 10:10 AM, Russell Bryant wrote: On 04/02/2014 11:01 AM, Solly Ross wrote: IMHO, having Example: on a separate line from the actual option is a lot easier for humans: you just delete a single character or use your editor-of-choice's uncomment macro to activate a line. Sure, agreed. But in any case, it seems to make sense to handle sample config files consistently across projects. If a usability enhancement related to examples is made, it will then make its way to all projects. Yes, and there seems to be some momentum behind the idea of getting these out of the git tree, so automatic generation is going to be needed then. We have a bug open (https://bugs.launchpad.net/oslo/+bug/1300546) for tracking what needs to happen for Glance to be able to do this, so if there's something blocking Neutron please let us know and we will figure out how to make it work. Thanks. -Ben ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Missleading and hardly parseable default neutron config files
On 04/02/2014 11:01 AM, Solly Ross wrote: IMHO, having Example: on a separate line from the actual option is a lot easier for humans: you just delete a single character or use your editor-of-choice's uncomment macro to activate a line. Sure, agreed. But in any case, it seems to make sense to handle sample config files consistently across projects. If a usability enhancement related to examples is made, it will then make its way to all projects. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Tuskar][Horizon] Javascript linter
I don't see why the license of a piece of software used to check the codebase (i.e. the linter) infects the codebase being checked. That would be like saying the Google terms of service under which I'm writing this email (Google Apps) infects the codebase. -- Kili - Cloud for Africa: kili.io Musings: twitter.com/varud https://twitter.com/varud More Musings: varud.com About Adam: www.linkedin.com/in/adamcnelson On Wed, Apr 2, 2014 at 6:53 PM, Ben Nemec openst...@nemebean.com wrote: I think that would be a good idea. We're not shipping this, we're just using it in test (AIUI), so I don't think incompatibility with the OpenStack license is necessarily an issue. But IANAL. :-) -Ben On 04/02/2014 09:24 AM, Kevin Conway wrote: I understand, and appreciate, the concern for licensing, but it would be a real shame to discount some of the most widely used linters because of a clause that prevents us from being evil. Any chance we could run this by legal-disc...@lists.openstack.org and hear their reactions before we axe the JS*int projects from OpenStack? On 4/2/14 8:43 AM, Radomir Dopieralski openst...@sheep.art.pl wrote: On 02/04/14 15:26, Kevin Conway wrote: What licensing issues were brought up that prevent the use of JSLint or JSHint? Both are MIT licensed. Granted, JSLint has an additional clause: The Software shall be used for Good, not Evil. Maybe that's it? If so, Crockford has been known to make exceptions for organizations that wish to use his code for potentially evil purposes: https://www.youtube.com/watch?v=-C-JoyNuQJsfeature=player_ detailpage#t=2 480s. Yes, that's exactly it. An exception is not enough -- that clause simply makes that license incompatible with OpenStack's license. To use it, we would need to change OpenStack's license too, and it quickly becomes quite complex. You have to remember that organizations like NSA use OpenStack, so we can't possibly include that clause in its license ;) -- Radomir Dopieralski ___ 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] Missleading and hardly parseable default neutron config files
On 04/02/2014 11:01 PM, Solly Ross wrote: IMHO, having Example: on a separate line from the actual option is a lot easier for humans: you just delete a single character or use your editor-of-choice's uncomment macro to activate a line. Please re-read what I wrote. There's things like: # Example: # directive = value # some-comments # directive = value So your argument doesn't work, since there's already a just delete a char kind of things, it's just there TWICE !!! Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Murano] MuranoPL = UML visualization - best implementation practices?
On Wed, Apr 2, 2014 at 7:54 PM, Ed Cranford ed.cranf...@rackspace.comwrote: Granted, it'll take some work to build a similar visual style--I see elaborate record nodes in your future--but you don't have to be bound to PlantUML if you don't want to be. I've used Graphviz before for a few applications, and if I can help get you started with building dot files, let me know. Actually I've tried to generate GraphViz input data (in .dot format) directly from MuranoPL manifests, and the result was a little disappointment. Graphs looked fine until the number of nodes were relatively small (less then 4), and dependencies between them remain linear. As soon as the number of nodes increases, or cross links appears, the graph becomes a mess. So that's why we decided to look for some external tool. And now we trying to find another tool which doesn't requires such heavy dependencies as Java. :) I'm not shure that writing our own tool worth it, however I might be wrong here. -- Thanks, Dmitry Teselkin Deployment Engineer Mirantis http://www.mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova] icehouse-rc1 libvirt broken - VIR_DOMAIN_START_PAUSED
I tried icehouse-rc1 in my libvirt-Xen environment, and found that instance launches were failing. Some digging determined that it was caused by use of the libvirt VIR_DOMAIN_START_PAUSED flag, which is not supported with Xen. I was about to report this when Google found: https://bugs.launchpad.net/nova/+bug/1301453 I realise that libvirt-Xen is Group C, but I think this is a show-stopping issue, and it seems to affect platforms other than Xen (maybe anything other than Qemu/KVM), based on Andrew's bug report. ~iain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] [IPv6] Ubuntu PPA with IPv6 enabled, need help to achieve it
Okay, cool! I'll... Tks! On 2 April 2014 12:49, Collins, Sean sean_colli...@cable.comcast.comwrote: On Wed, Apr 02, 2014 at 11:40:39AM EDT, Martinx - ジェームズ wrote: But, can this current neutron-ipv6.patch at least, be used to enable Neutron IPv6 with RA (--ipv6_ra_mode slaac --ipv6_address_mode slaac) ? No, because even if you solved all the merge conflicts, the tests were not passing in the last patch set. Keep an eye on the ML and the subteam IRC meeting, I'll make sure to add an agenda item for next week to discuss backporting potential. -- Sean M. Collins ___ 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] [Tuskar][Horizon] Javascript linter
I agree - it's not a viral license, and we're not shipping it anyway. I'm going to go back to the original thing: Recently we have been discussing the topic of Javascript linters for Horizon and Tuskar-UI with Radomir, and he told me that JSLint and JSHint can not be integrated into the test environment due to some license issues. This is just not true. In fact, we have a full grunt-based jslint gate on storyboard-webclient running in infra currently. It's integrated with tox even. I suggest: a) use jslint b) use it via grunt c) use grunt via tox and nodeenv d) use the job templates we have in infra to run this sort of thing I'm happy to help point people to how this works. On 04/02/2014 09:10 AM, Adam Nelson wrote: I don't see why the license of a piece of software used to check the codebase (i.e. the linter) infects the codebase being checked. That would be like saying the Google terms of service under which I'm writing this email (Google Apps) infects the codebase. -- Kili - Cloud for Africa: kili.io http://kili.io/ Musings: twitter.com/varud https://twitter.com/varud More Musings: varud.com http://varud.com/ About Adam: www.linkedin.com/in/adamcnelson https://www.linkedin.com/in/adamcnelson On Wed, Apr 2, 2014 at 6:53 PM, Ben Nemec openst...@nemebean.com mailto:openst...@nemebean.com wrote: I think that would be a good idea. We're not shipping this, we're just using it in test (AIUI), so I don't think incompatibility with the OpenStack license is necessarily an issue. But IANAL. :-) -Ben On 04/02/2014 09:24 AM, Kevin Conway wrote: I understand, and appreciate, the concern for licensing, but it would be a real shame to discount some of the most widely used linters because of a clause that prevents us from being evil. Any chance we could run this by legal-discuss@lists.openstack.__org mailto:legal-disc...@lists.openstack.org and hear their reactions before we axe the JS*int projects from OpenStack? On 4/2/14 8:43 AM, Radomir Dopieralski openst...@sheep.art.pl mailto:openst...@sheep.art.pl wrote: On 02/04/14 15:26, Kevin Conway wrote: What licensing issues were brought up that prevent the use of JSLint or JSHint? Both are MIT licensed. Granted, JSLint has an additional clause: The Software shall be used for Good, not Evil. Maybe that's it? If so, Crockford has been known to make exceptions for organizations that wish to use his code for potentially evil purposes: https://www.youtube.com/watch?__v=-C-JoyNuQJsfeature=player___detailpage#t=2 https://www.youtube.com/watch?v=-C-JoyNuQJsfeature=player_detailpage#t=2 480s. Yes, that's exactly it. An exception is not enough -- that clause simply makes that license incompatible with OpenStack's license. To use it, we would need to change OpenStack's license too, and it quickly becomes quite complex. You have to remember that organizations like NSA use OpenStack, so we can't possibly include that clause in its license ;) -- Radomir Dopieralski _ OpenStack-dev mailing list OpenStack-dev@lists.openstack.__org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _ OpenStack-dev mailing list OpenStack-dev@lists.openstack.__org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _ OpenStack-dev mailing list OpenStack-dev@lists.openstack.__org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev 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] Missleading and hardly parseable default neutron config files
On 04/02/2014 06:38 PM, Salvatore Orlando wrote: Hi Thomas, it probably won't be a bad idea if you can share the patches you're applying to the default configuration files. I think all distros are patching them anyway, so this might allow us to provide mostly ready to use config files. Is there a chance you can push something to gerrit? Salvatore Hi, here it is: https://review.openstack.org/84809 If only a subset of my changes are accepted, that's already some progress for me. I will also enjoy comments, so feel free to let me know if what I'm doing is stupid! :) Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] icehouse-rc1 libvirt broken - VIR_DOMAIN_START_PAUSED
On 04/02/2014 12:37 PM, iain macdonnell wrote: I tried icehouse-rc1 in my libvirt-Xen environment, and found that instance launches were failing. Some digging determined that it was caused by use of the libvirt VIR_DOMAIN_START_PAUSED flag, which is not supported with Xen. I was about to report this when Google found: https://bugs.launchpad.net/nova/+bug/1301453 I realise that libvirt-Xen is Group C, but I think this is a show-stopping issue, and it seems to affect platforms other than Xen (maybe anything other than Qemu/KVM), based on Andrew's bug report. Given that these platforms are group C (untested), I do not consider this a release blocker. If it gets fixed, that would be great. Otherwise, it will just have be noted as a known issue in the initial Icehouse release and fixed later with a backport. In the meantime, I have added this as a known issue for Nova here: https://wiki.openstack.org/wiki/ReleaseNotes/Icehouse -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Tuskar][Horizon] Javascript linter
On my phone so I can't follow this up more now, but it looks like JSHint is already used. https://review.openstack.org/#/c/41087/___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Tuskar][Horizon] Javascript linter
On 04/02/2014 07:36 PM, Dougal Matthews wrote: On my phone so I can't follow this up more now, but it looks like JSHint is already used. https://review.openstack.org/#/c/41087/ That commit has since been reverted and JSHint removed from Horizon codebase: https://bugs.launchpad.net/horizon/+bug/1270764 https://review.openstack.org/#/c/68268/ Seems like there's some controversy around whether the licenses are actually incompatible or not. How do we go about clearing that up? :) -- Regards, Ana Krivokapic Associate Software Engineer OpenStack team Red Hat Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All][Keystone] Deprecation of the v2 API
On Wed, 2014-04-02 at 17:08 +, Tim Bell wrote: I’ve added the depreciation process to the section on meet the PTLs/TC for the Atlanta Ops unconference (https://etherpad.openstack.org/p/ATL-ops-unconference-RFC). Currently, it is difficult to tell how much a particular feature is being used and the impact of depreciation. Exercising my penchant for precision: depreciation or deprecation? I hope that the openstack code base isn't depreciating, even if parts of it are being deprecated :) -- Kevin L. Mitchell kevin.mitch...@rackspace.com Rackspace ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Tuskar][Horizon] Javascript linter
On 04/02/2014 11:05 AM, Ana Krivokapic wrote: On 04/02/2014 07:36 PM, Dougal Matthews wrote: On my phone so I can't follow this up more now, but it looks like JSHint is already used. https://review.openstack.org/#/c/41087/ That commit has since been reverted and JSHint removed from Horizon codebase: https://bugs.launchpad.net/horizon/+bug/1270764 https://review.openstack.org/#/c/68268/ Seems like there's some controversy around whether the licenses are actually incompatible or not. How do we go about clearing that up? :) I was a little unclear before. Two things: - We should use the same stuff we've put together for storyboard - It is not needed to include jshint in the codebase to be able to use it To expand on the second point - we've found tooling to allow us to integrate things like jshint into python virtualenv (just go ahead and be amazed) So it's entirely possible to do _ALL_ of this in a way that is consistent with how we work in OpenStack. Check out these two patches to zuul: https://review.openstack.org/#/c/82307/ https://review.openstack.org/#/c/82308/ Which show incorporating it into a standing python project. If I get a chance this weekend - I can try to cook up a similar one for horizon/tuskar if nobody beats me to it. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Support for multiple sort keys and sort directions in REST GET APIs
I have proposed blueprints in both nova and cinder for supporting multiple sort keys and sort directions for the GET APIs (servers and volumes). I am trying to get feedback from other projects in order to have a more uniform API across services. Problem description from nova proposal: There is no support for retrieving server data in a specific order, it is defaulted to descending sort order by the created date and id keys. In order to retrieve data in any sort order and direction, the REST APIs need to accept multiple sort keys and directions. Use Case: A UI that displays a table with only the page of data that it has retrieved from the server. The items in this table need to be sorted by status first and by display name second. In order to retrieve data in this order, the APIs must accept multiple sort keys/directions. See nova proposal .rst file (cinder is basically the same) for more information: https://review.openstack.org/#/c/84451/ Most projects have similar GET requests and I am trying to get some consensus on this approach across the various projects; the goal is to have this type of functionality common across projects (not just nova and cinder). Note that some projects (ie, cinder) already support a single sort key and sort direction, see https://github.com/openstack/cinder/blob/master/cinder/api/v2/volumes.py#L212-L213 Note that the DB layer already accepts multiple sort keys and sort directions (see https://github.com/openstack/oslo-incubator/blob/master/openstack/common/db/sqlalchemy/utils.py#L62), the work I am describing here only exposes the sorting options at the REST API layer. Please provide feedback on this direction. Specifically, do you see any issues (and, if so, why) with allowing the caller to specify sort orders and directions on the GET APIs? Feel free to leave your feedback in the Gerrit review for the nova blueprint or reply to this thread. Thanks, Steven Kaufer___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Summit session for config validation and diagnostic
Oleg, Seems like very interesting topic. Especially I am interested in how could be this integrated with production clouds (could it be run on controllers?). What API it present and is there integration with horizon? Best regards, Boris Pavlovic On Wed, Apr 2, 2014 at 11:20 PM, Oleg Gelbukh ogelb...@mirantis.com wrote: Hello, OpenStack developers Everyone knows that finding out the root cause of some failure in OpenStack with many projects interacting with each other and external components could be serious challenge even for seasoned stacker. I've seen more than one attempt to attack this task since I joined this community (including our own project Rubick). Now I want to make somewhat bold attempt to bring all interested parties face to face in Atlanta during a summit session in 'Other projects' track: http://summit.openstack.org/cfp/details/208 I see it as a good place to coordinate efforts scattered across multiple projects now. Let's find out what are most important and common use cases for us, and outline how we're going to solve them. What do you think? -- Best regards, Oleg Gelbukh Mirantis Labs ___ 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] [QA] Meeting Thursday April 3rd at 22:00UTC
Just a quick reminder that the weekly OpenStack QA team IRC meeting will be tomorrow Thursday, April 3rd at 22:00 UTC in the #openstack-meeting channel. The agenda for tomorrow's meeting can be found here: https://wiki.openstack.org/wiki/Meetings/QATeamMeeting Anyone is welcome to add an item to the agenda. To help people figure out what time 22:00 UTC is in other timezones tomorrow's meeting will be at: 18:00 EDT 07:00 JST 08:30 ACDT 23:00 CET 17:00 CDT 15:00 PDT -Matt Treinish ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron LBaaS] Need help with LBaaS drivers
Hi VijayV, Oleg!
Thanks for the pointers! It turns out I had to put in an __init__.py in the
dummy/ directory, else the driver wouldn't get loaded. Now I see newer
issues, and am trying to fix those. I'll ping back on how that goes and if
I have any questions..
Cheers!
Regards,
Vijay
On Wed, Apr 2, 2014 at 1:34 AM, Oleg Bondarev obonda...@mirantis.comwrote:
Hi Vijay,
Currently you may follow two ways in writing an LBaaS driver:
1) write it from scratch (like Radware, Netscaler, Embrane drivers) -
in this case your driver should inherit
abstract_driver.LoadBalancerAbstractDriver
and
will be running on Neutron service process, LBaaS agent won't be used.
So you should restart not q-lbaas but q-svc process in order for new
driver to be used and it should work with the steps you've described.
2) leverage
neutron/services/loadbalancer/drivers/common/agent_drive_base.py framework
and in fact write only device driver which inheritits
neutron.services.loadbalancer.agent.agent_device_driver.AgentDeviceDriver.
This is how HAProxy driver is implemented, please see
neutron/services/loadbalancer/drivers/haproxy/plugin_driver.py
and namespace_driver.py (this is device driver).
Along with updating service_provider in neutron.conf you should also
add your device driver to lbaas_agent.ini file (again please check how it
is done for haproxy)
In this case your driver will be running on LBaaS agent and you should
restart both q-svc and q-lbaas.
Generally, the second approach is preferable as it's better scalable and
provides you a built-in async mechanism.
Thanks,
Oleg
On Wed, Apr 2, 2014 at 5:44 AM, Vijay B os.v...@gmail.com wrote:
Hi,
I'm trying to understand how LBaaS drivers work and so am attempting to
write a dummy driver that does nothing for now, but instead of loading my
dummy driver, neutron always loads the HAProxy namespace driver. These are
the steps I followed:
1) I created a new directory
neutron/services/loadbalancer/drivers/dummy/, and in that directory I
put in a new file dummy_driver.py, which basically has a class class
DummyPluginDriver(abstract_driver.LoadBalancerAbstractDriver):
and has empty __init__(), create_vip(), delete_vip() etc functions.
2) I'm testing using a devstack setup, so I also edited the
/etc/neutron/neutron.conf file, commenting out the default loadbalancer
driver entry for HAProxy, and added a line for my dummy driver as follows:
service_provider=LOADBALANCER:Dummy:neutron.services.loadbalancer.drivers.dummy.dummy_driver.DummyPluginDriver:default
3) I created a /etc/neutron/services/loadbalancer/dummy/lbaas_agent.ini
directory/file
I simply copied over the haproxy's lbaas_agent.ini file and changed
[haproxy] to [dummy]
and then I restarted the q-lbaas service using cd /opt/stack/neutron
python /usr/local/bin/neutron-lbaas-agent --config-file
/etc/neutron/neutron.conf
--config-file=/etc/neutron/services/loadbalancer/dummy/lbaas_agent.ini
However, I see that the default HAProxyNS driver is still being loaded
When I put a breakpoint in loadbalancer/agent/agent_manager.py:86, I see
this (relevant text marked in red):
2014-03-31 13:47:16.998 DEBUG neutron.common.utils [-] Reloading cached
file /etc/neutron/policy.json from (pid=28405) read_cached_file
/opt/stack/neutron/neutron/common/utils.py:53
2014-03-31 13:47:16.998 DEBUG neutron.policy [-] Loading policies from
file: /etc/neutron/policy.json from (pid=28405) _set_rules
/opt/stack/neutron/neutron/policy.py:89
/opt/stack/neutron/neutron/services/loadbalancer/agent/agent_manager.py(86)_load_drivers()
- self.device_drivers = {}
(Pdb) l
81 # pool_id-device_driver_name mapping used to store known
instances
82 self.instance_mapping = {}
83
84 def _load_drivers(self):
85 import pdb; pdb.set_trace()
86 - self.device_drivers = {}
87 for driver in self.conf.device_driver:
88 try:
89 driver_inst = importutils.import_object(
90 driver,
91 self.conf,
(Pdb) self.conf.device_driver
['neutron.services.loadbalancer.drivers.haproxy.namespace_driver.HaproxyNSDriver']
(Pdb)
I'm not sure what I'm doing wrong - am I missing something that needs to
be done within the dummy driver itself? (in dummy_driver.py?). Should I
register some opts or similar?
Any help would be much appreciated!
Thanks,
Regards,
Vijay
___
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
[openstack-dev] [heat] metadata for a HOT
I would like to suggest that a metadata section be allowed at the top level of a HOT. Note that while resources in a stack can have metadata, there is no way to put metadata on a stack itself. What do you think? Thanks, Mike___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] metadata for a HOT
On 02/04/14 16:45, Mike Spreitzer wrote: I would like to suggest that a metadata section be allowed at the top level of a HOT. Note that while resources in a stack can have metadata, there is no way to put metadata on a stack itself. What do you think? I think that if you're going to propose a new feature, you should at least give us a clue who you think is going to use it and what for ;) IIRC this has been discussed in the past and the justifications for including it in the template (as opposed to allowing metadata to be attached in the ReST API, as other projects already do for many things) were not compelling. cheers, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Heat] [Murano] [Solum] applications in the cloud
This is a continuation of the MuranoPL questions thread. As a result of ongoing discussions, we figured out that definition of layers which each project operates on and has responsibility for is not yet agreed and discussed between projects and teams (Heat, Murano, Solum (in alphabetical order)). Our suggestion and expectation from this working group is to have such a definition of layers, agreement on it and an approach of reaching it. As a starting point, we suggest the following: There are three layers of responsibility: 1. Resources of the cloud 2. Applications of the cloud 3. Layers specific for Murano and Solum (to be further discussed and clarified, for this discussion it's out of scope) Layer 1 is obviously covered by Heat. Most of the disagreement is around layer 2. Our suggestion is to figure out the way where we can have common engine, DSL and approach to apps description. For this we'll take HOT and TOSCA as a basis and will work on addition of functionality missing from Murano and Solum point of view. We'll be happy if existing Heat team continue working on it, having the full control of the project, provided that we agree on functionality missing there from Murano and Solum point of view and addition of this functionality in a systematic way. Let me outline the main concern in regards to HOT from Murano perspective. Others concerns could be figured out later. The typical use case for Murano is the following: Application writer sets a requirement for her application to use RDBMS assuming that it can be MySQL, PostgreSQL or MSSQL. HOT engine should be able to understand such requirements and be able to satisfy them by instantiating instances with DB. End user should be able to control which particular type of DB should be used. This is quite similar to abstract requirements described in TOSCA. As Heat wants to cover TOSCA format too this Murano requirement is pretty well aligned with what HOT\TOSCA can provide. Hopefully this functionality can be introduced into HOT. Solum and Murano will leverage it by using some common API, and implementing layer 3 as thin as possible. Again, this is only suggested starting point, something to begin with. Thanks, Ruslan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer] PTL candidacy
confirmed On 04/02/2014 04:47 PM, Gordon Chung wrote: hi, i'd like to announce my candidacy for PTL of Ceilometer. as a little background, i've been a contributor to OpenStack for the past year and a half and have been primarily focused on Ceilometer for the past two cycles where i've been a core contributor. i contribute regularly to the project with code [1] and am one of the top reviewers [2]. i am also a developer at IBM where i work on the IBM software standards team, building standards such as the Cloud Audit Data Federation Working Group (CADF) specification. there's a great deal to be discussed at the upcoming summit and i'm sure Ceilometers' contributors and deployers have a lot of ideas. in addition to those, i think some key items to focus on are: - improving collector performance in Ceilometer. this has been a major item in Ceilometer recently as we tried to expand our integration tests in tempest and have found there are inefficiencies in how Ceilometer is collecting data. Ceilometer should be a lightweight service, capable of processing heavy load and we need to ensure it can handle this. i'd like to revisit our models (to ensure our model match what operators require) and build our backends around this so they are highly tuned to writes and reads for these use cases. - improving polling agents. the compute agent currently creates a heavy load on compute-api[3] and the central agent has it's own performance and HA issues... it's something we should really considering looking at. - continue to expand tempest testing in ceilometer. the tempest tests have been helpful in identifying gaps/performance issues and will help later in identifying regression. - review how we log in Ceilometer. we have a very repetitive framework design so our logs can be extremely overwhelming or extremely sparse. some other items to track (depending on resource) are: - enhancing event support. there is a framework for events in Ceilometer but there is work to be done to make it a true monitoring tool. we have a few blueprints existing in Ceilometer that should help. - re-evaluating the alarming service. we currently require two services to run for alarms, a notifier and an evaluator which also depends on the ceilometerclient. there is an interesting bp to move some alarm logic to the pipeline and i think we should take a look at it to see if it provides a cleaner, leaner solution.[4]. if not, we should work on documenting our current implementation. [1] https://review.openstack.org/#/q/owner:chungg+status:merged+project:openstack/ceilometer,n,z [2] http://russellbryant.net/openstack-stats/ceilometer-reviewers-365.txt [3] http://openstack-in-production.blogspot.ca/2014/03/cern-cloud-architecture-update-for.html [4] https://blueprints.launchpad.net/ceilometer/+spec/alarm-pipelines cheers, gordon chung openstack, ibm software standards ___ 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] [TripleO] PTL Candidacy
I'm running for TripleO PTL again! Over the last 6 months TripleO has come a long way in the last 6 months: - CI on all changes (not yet gating) - Persistent storage on nodes - a significantly increased community I've been thrilled to see our progress - and the more time we spend running running clouds the more feedback we generate to other OpenStack programs. My view on PTL is unchanged from 6 months ago - it is an enabling position: working with the team to identify blockers, constraints issues and weak points in the (design/code/architecture) and then respectively remove/socialise and target them. I think I fell short of that aspiration in the last cycle, and commit to doing better if I am elected. For folk who are new to the community in the last 6 months, this was my platform last time - http://lists.openstack.org/pipermail/openstack-dev/2013-September/015431.html Last cycle I said Icehouse is the first opportunity we'll have to have a fully functional story, and even now thats still a fairly aggressive goal : my focus over the next 6 months will be getting us out of fire-drill mode and into the steady-state that is needed for confident deployments... in addition to fleshing out the features required for Tuskar, overcloud upgrades and undercloud upgrades. That means, in big ticket items... I believe the delivery of scaled CI has been a crucial step - we no longer break ourselves, and we find out quickly when changes elsewhere in openstack break the tripleo tooling. Thats been invaluable so far - and will be more so as we broaden CI and make it voting and then gating. To my mind over the next 6 months we need to focus on * Continuing the CI path * HA of everything out of the box * Graceful upgrades * pushing our deployment experience feedback to the project we deploy * expanding our coverage to deploy everything * Migrating to Tuskar for everything but the deployment of the seed Obviously, if you have questions please ask! -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] PTL Candidacy
confirmed On 04/02/2014 06:23 PM, Robert Collins wrote: I'm running for TripleO PTL again! Over the last 6 months TripleO has come a long way in the last 6 months: - CI on all changes (not yet gating) - Persistent storage on nodes - a significantly increased community I've been thrilled to see our progress - and the more time we spend running running clouds the more feedback we generate to other OpenStack programs. My view on PTL is unchanged from 6 months ago - it is an enabling position: working with the team to identify blockers, constraints issues and weak points in the (design/code/architecture) and then respectively remove/socialise and target them. I think I fell short of that aspiration in the last cycle, and commit to doing better if I am elected. For folk who are new to the community in the last 6 months, this was my platform last time - http://lists.openstack.org/pipermail/openstack-dev/2013-September/015431.html Last cycle I said Icehouse is the first opportunity we'll have to have a fully functional story, and even now thats still a fairly aggressive goal : my focus over the next 6 months will be getting us out of fire-drill mode and into the steady-state that is needed for confident deployments... in addition to fleshing out the features required for Tuskar, overcloud upgrades and undercloud upgrades. That means, in big ticket items... I believe the delivery of scaled CI has been a crucial step - we no longer break ourselves, and we find out quickly when changes elsewhere in openstack break the tripleo tooling. Thats been invaluable so far - and will be more so as we broaden CI and make it voting and then gating. To my mind over the next 6 months we need to focus on * Continuing the CI path * HA of everything out of the box * Graceful upgrades * pushing our deployment experience feedback to the project we deploy * expanding our coverage to deploy everything * Migrating to Tuskar for everything but the deployment of the seed Obviously, if you have questions please ask! -Rob ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] PTL candidacy
confirmed On 04/02/2014 06:51 PM, Mark Washenberger wrote: Hi all, I'd like to submit myself as a candidate to continue in the role of Glance PTL for the Juno release cycle. A bit of history about me: I joined Rackspace's Team Titan back in February 2011, where were initially focused on filling out the OpenStack 1.1 api for nova. I've been working with Glance apis and core functionality for about 5 cycles now. Since November 2012 I've been an employee of Nebula, working alongside some of the original NASA OpenStack folks and the former Glance PTL Brian Waldon (until he left to go manufacture oreos). As Juno PTL, I expect to proceed much in the same way as during Havana and Icehouse, hopefully with lots of realized opportunities for incremental improvement. I'm very open to any advice, suggestions, or other contributors who want to take on more responsibility in the near future. Thank you, markwash ___ 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] [Tuskar][Horizon] Javascript linter
+1 on talking to lawyers. Some more context: JSHint is a fork of JSLint, from which the problem license originates. The team has made a significant effort to strip out and replace JSLint code, however there remains one file which they haven’t tackled yet. There’s a large discussion here, including a statement where the author of the original license calls it “ineffective”. https://github.com/jshint/jshint/issues/1234 Michael On Apr 2, 2014, at 7:24 AM, Kevin Conway kevinjacobcon...@gmail.com wrote: I understand, and appreciate, the concern for licensing, but it would be a real shame to discount some of the most widely used linters because of a clause that prevents us from being evil. Any chance we could run this by legal-disc...@lists.openstack.org and hear their reactions before we axe the JS*int projects from OpenStack? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone] python-keystoneclient v3 functionality
- Original Message - From: Adam Young ayo...@redhat.com To: openstack-dev@lists.openstack.org Sent: Wednesday, 2 April, 2014 11:13:22 PM Subject: Re: [openstack-dev] [Keystone] python-keystoneclient v3 functionality On 04/01/2014 07:36 AM, Yaguang Tang wrote: Thanks Jamie, then the following question is do we intend to move other services client library V3 identity support to python-openstackclient? AFAIK it's poorly supported for Nova Cinder Neutron client library, and I am working on add v3 support for those libraries[1], just want to make sure that is the correct direction. [1] https://review.openstack.org/#/c/81749/ https://review.openstack.org/#/c/81767/ Sort of. The Keystone client should be responsible for all fo the service catalog manipulations throughout openstack. So the Cinder client should use the Keystone client. To see the idea, read Jamie's blog post: http://www.jamielennox.net/blog/2014/02/24/client-session-objects/ The main idea is that Keystone will handle the HTTP session setup, so that we have a single place to focus attention on for HTTP network security issues. And you should not need to parse the service catalog at all. So Adam is right in that the general idea to transition people to using the V3 API will be to use the keystoneclient.session.Session object and that will do everything for you. This is not going to be an easy transition for everyone and i've got a summit session proposed: http://summit.openstack.org/cfp/details/205 in which i want to deal with precisely this problem. Regarding your notion of openstackclient though, you need to seperate the concept of a CLI and the library. Take for example Heat or Horizon, they communicate with keystone through the python-keystoneclient and nova via the python-novaclient etc. They do not use the keystone or nova cli utility. The primary job of the python-*client libraries is NOT to provide a cli. The cli is just an application that makes use of the library. So yes, i think it has generally been accepted that the clients will move (at there own pace) to using openstackclient for there CLI, but openstackclient will still rely on the various libraries to do the actual communication with services. Jamie 2014-04-01 12:08 GMT+08:00 Jamie Lennox jamielen...@redhat.com : On Tue, 2014-04-01 at 11:53 +0800, Yaguang Tang wrote: Hi all, I am sorry if this has been discussed before, the question is will we support keystone v3 operation in python-keystoneclient? I know most of the v3 functionality have been implemented in python-openstackclient, but from the python-openstackclient wiki says, it's primarily a wrapper of python-*client, and provides unified interface to user. The end user uses python-keystoneclient to manage user, tenant, service before, if we don't intend to support v3 functionality in keystoneclient, then it means we force end user to change from keystoneclient to openstackclient, is this what we want to do? It depends what you mean by python-keystoneclient. If you mean the python library then yes it supports the V3 API already. If you mean the keystone CLI that is currently bundled as part of the python-keystoneclient then yes that is deprecated in favour of python-openstackclient. We will maintain the CLI application in keystoneclient however even for V2 API calls I recommend that you use the openstack CLI tool. Jamie -- Tang Yaguang Canonical Ltd. | www.ubuntu.com | www.canonical.com Mobile: +86 152 1094 6968 gpg key: 0x187F664F ___ 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 -- Tang Yaguang Canonical Ltd. | www.ubuntu.com | www.canonical.com Mobile: +86 152 1094 6968 gpg key: 0x187F664F ___ 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] [ceilometer] PTL candidacy
On 04/02/2014 05:47 PM, Gordon Chung wrote: I'd like to announce my candidacy for PTL of Ceilometer. Woot! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] [Murano] [Solum] applications in the cloud
On 03/04/14 10:39, Ruslan Kamaldinov wrote:
This is a continuation of the MuranoPL questions thread.
As a result of ongoing discussions, we figured out that definition of layers
which each project operates on and has responsibility for is not yet agreed
and discussed between projects and teams (Heat, Murano, Solum (in
alphabetical order)).
Our suggestion and expectation from this working group is to have such
a definition of layers, agreement on it and an approach of reaching it.
As a starting point, we suggest the following:
There are three layers of responsibility:
1. Resources of the cloud
2. Applications of the cloud
3. Layers specific for Murano and Solum (to be further discussed and
clarified, for this discussion it's out of scope)
Layer 1 is obviously covered by Heat.
Most of the disagreement is around layer 2. Our suggestion is to figure out
the way where we can have common engine, DSL and approach to apps description.
For this we'll take HOT and TOSCA as a basis and will work on addition of
functionality missing from Murano and Solum point of view.
We'll be happy if existing Heat team continue working on it, having the full
control of the project, provided that we agree on functionality missing there
from Murano and Solum point of view and addition of this functionality in a
systematic way.
Let me outline the main concern in regards to HOT from Murano perspective.
Others concerns could be figured out later. The typical use case for Murano is
the following:
Application writer sets a requirement for her application to use RDBMS
assuming that it can be MySQL, PostgreSQL or MSSQL. HOT engine should be able
to understand such requirements and be able to satisfy them by instantiating
instances with DB. End user should be able to control which particular type of
DB should be used. This is quite similar to abstract requirements described in
TOSCA. As Heat wants to cover TOSCA format too this Murano requirement is
pretty well aligned with what HOT\TOSCA can provide.
Hopefully this functionality can be introduced into HOT. Solum and Murano will
leverage it by using some common API, and implementing layer 3 as thin as
possible.
Again, this is only suggested starting point, something to begin with.
Thanks for bring this discussion back to solving specific problems. The
above database abstraction can be nicely represented using HOT
environments and provider resources [1].
Take the following template snippet:
resources:
my_db:
type: My::Database
properties:
# ...
my_server
type: OS::Nova::Server
properties:
# ... including a {get_attr: [my_db, connection_url]}
My::Database is a type defined in the environment which is included in
the stack-create call. Different environments can provide different
database implementations, for example:
resource_registry:
My::Database: path/to/trove_wrapper.yaml
resource_registry:
My::Database: path/to/nova_galera_ubercluster.yaml
resource_registry:
My::Database: path/to/postgresql.yaml
Each of these templates could be implemented to have the same parameters
and outputs so the template will work with any of these resource
provider templates.
One thing we could consider adding to HOT is allow the defining of a
type interface, and validating that a given template/resource implements
its declared interfaces. However the above example works just fine
without interfaces, and this duck-typing approach may provide a better
user experience anyway.
[1] http://docs.openstack.org/developer/heat/template_guide/environment.html
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Mistral] Next crack at real workflows
Two more workflows drafted - cloud cron, and lifecycle, version 1. The mindset questions are: 1) is DSL syntax expressive, and capable and convenient to handle real use cases? 2) most importantly: what are the implied workflow capabilities which make it all work? * Take a look here: https://github.com/dzimine/mistral-workflows/tree/add-usecases * Leave your comments - generally, or line-by-line, in the pull request https://github.com/dzimine/mistral-workflows/pull/1/files * Fork, do your own modifications and do another pull request. * Or just reply with your comments in email (lazy option :)) NOTE: please keep this thread for specific comments on DSL and workflow capabilities, create another thread if changing topic. Thanks! DZ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Oslo][Nova][Heat] Sample config generator issue
We have an issue in Heat where the sample config generator from Oslo is currently broken (see bug #1288586). Unfortunately it turns out that there is no fix to the generator script itself that can do the Right Thing for both Heat and Nova. A brief recap on how the sample config generator works: it goes through all of the files specified and finds all the ConfigOpt objects at the top level. It then searches for them in the registered options, and returns the name of the group in which they are registered. Previously it looked for the identical object being registered, but now it just looks for any equivalent ones. When you register two or more equivalent options, the second and subsequent ones are just ignored by oslo.config. The situation in Heat is that we have a bunch of equivalent options registered in multiple groups. This is because we have a set of options for each client library (i.e. python-novaclient, python-cinderclient, c.), with each set containing equivalent options (e.g. every client has an endpoint_type option for looking up the keystone catalog). This used to work, but now that equivalent options (and not just identical options) match when searching for them in a group, we just end up with multiple copies of each option in the first group to be searched, and none in any of the other groups, in the generated sample config. Nova, on the other hand, has the opposite problem (see bug #1262148). Nova adds the auth middleware from python-keystoneclient to its list of files to search for options. That middleware imports a file from oslo-incubator that registers the option in the default group - a registration that is *not* wanted by the keystone middleware, because it registers an equivalent option in a different group instead (or, as it turns out, as well). Just to make it interesting, Nova uses the same oslo-incubator module and relies on the option being registered in the default group. Of course, oslo-incubator is not a real library, so it gets registered a second time but ignored (since an equivalent one is already present). Crucially, the oslo-incubator file from python-keystoneclient is not on the list of extra modules to search in Nova, so when the generator script was looking for options identical to the ones it found in modules, it didn't see this option at all. Hence the change to looking for equivalent options, which broke Heat. Neither comparing for equivalence nor for identity in the generator script can solve both use cases. It's hard to see what Heat could or should be doing differently. I think it follows that the fix needs to be in either Nova or python-keystoneclient in the first instance. One option I suggested was for the auth middleware to immediately deregister the extra option that had accidentally been registered upon importing a module from oslo-incubator. I put up patches to do this, but it seemed to be generally agreed by Oslo folks that this was a Bad Idea. Another option would be to specifically include the relevant module from keystoneclient.openstack.common when generating the sample config. This seems quite brittle to me. We could fix it by splitting the oslo-incubator module into one that provides the code needed by the auth middleware and one that does the registration of options, but this will likely result in cascading changes to a whole bunch of projects. Does anybody have any thoughts on what the right fix looks like here? Currently, verification of the sample config is disabled in the Heat gate because of this issue, so it would be good to get it resolved. cheers, Zane. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] [NOVA] Missing network info in nova list
Hi Slawek, Interesting, I haven't seen this issue of network info not showing up on nova list and the instance being in ACTIVE state. Could you check out the nova logs and see if there are any TRACE's there? If you're using icehouse you should be able to do neutron port-update port_id that maps to the instance's port and doing that will send a notification to nova to update it's cache for the instance. Best, Aaron On Tue, Apr 1, 2014 at 12:10 AM, Sławek Kapłoński sla...@kaplonski.plwrote: Hello, Maybe the problem is not that missing data in nova's database becasue when I made: nova --debug list then I see that it is asking neutron about ports and this missing IP is corretly send from neutron. Also when I made: nova interface-list instance_id then there is no problem and IP is displayed. But still this IP is missing in list of instances and I displaying instance details (also in horizon). -- Best regards Sławek Kapłoński Dnia poniedziałek, 31 marca 2014 18:17:18 Sławek Kapłoński pisze: Hello, I have openstack installation with neutron. When I made test and create many instances in one query (using --num-instances) all was ok but one instance (from 80 created) has no IP address when I made nova list or nova show . I found that there is missing value in network info in nova database in Instance-info-cache table. Everything except that is working fine: port with this IP is assigned to instance in neutron, binding is ok, instance has got configured this IP and I can ping it. Maybe someone know why this informations are missing in nova database and how to refresh it? ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openst...@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ 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] [neutron]Success to create securitygroup with invalid tenant_id. Does it need to check the tenant_id?
Hi Lee, No, currently only an admin user can create something with a different tenant_id by default. The issue with validating the tenant_id is we need to involve keystone in order to check if the tenant_id is valid (which will cause things to slow down). I believe this question has already come up on the list before if you want to search the archive. This issue isn't specific to just security_groups in neutron its allowed with all neutron resources. Aaron On Tue, Apr 1, 2014 at 1:58 AM, 黎林果 lilinguo8...@gmail.com wrote: Hi, all Such as the subject, there is no mechanism to check the tenant_id, Do you think it is necessary? Thanks! Lee Li ___ 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] [ceilometer] Serveral questions about alarm function of ceilometer
Hi I have a requirement of monitoring VMs, if a VM's meter like cpu_util become too high, then system generate an alarm for this VM with meter information. I have tested alarm function of ceilometer, below are commands I used to create alarm object with meter and resource id or not: ceilometer alarm-threshold-create --name alarm1 --meter-name cpu_util --period 60 --evaluation-periods 1 --statistic avg --comparison-operator gt --threshold 1 -q resource_id=757dadaa-0707-4fad-808d-81edc11438aa ceilometer alarm-threshold-create --name alarm1 --meter-name cpu_util --period 60 --evaluation-periods 1 --statistic avg --comparison-operator gt --threshold 1 I have the following question: If I have to define alarm object for every VM and every meter? Take 100 VM and 2 meter cpu_util, memory_util as an example, I will have to define 100*2 alarm objects for them. I think if I just define alarm object with meter not but VM(resource_id), then alarm evaluator will count all VM's meter. Another question produced by question above: I know that alarm evaluator will process alarm object one by one, so too many alarm object may result in performance problems too. I am not a ceilometer programmer and I apologize if I am missing something very obvious. Can you give me some help to make me clear about them and how to implement my requirement? Thanks ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Cinder]a question about os-volume_upload_image
Hi, When I use an image to create a cinder volume, I found image's metadata is saved into DB table volume_glance_metadata. But when I use os-volume_upload_image to create image from cinder volume, the metadata in volume_glance_metadata is not setted back to the newly created image. I can't found the reason for this. Anyone can give me a hint? I am a newbie for cinder and i apologize if I am missing something very obvious. Best regards to you. Ricky ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Tempest][Nova] Can we remove XML tests of Nova v2 API from Tempest?
Hi, The XML support of Nova v2 API is marked as deprecated, and the message is 'XML support has been deprecated and will be removed in the Juno release.' with https://review.openstack.org/#/c/75439 Now we are in Juno cycle, so can we remove these tests from Tempest? If doing it, the gate testing time would shrink and the implementations of Nova v2 API test would be more easy. Thanks Ken'ichi Ohmichi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Standing down as PTL
Let's vote for the K, L, M release names now. :) Thanks, Steve. On Mon, Mar 31, 2014 at 11:22:49AM +1300, Steve Baker wrote: I don't intend to run for PTL for the Juno cycle; thankfully there are many Heat developers who would do a great job. Hopefully this wasn't a one-off though. I may run again for Kilmacow, Lacrosse or Mooball. cheers ___ 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] [Keystone] python-keystoneclient v3 functionality
2014-04-03 7:12 GMT+08:00 Jamie Lennox jamielen...@redhat.com: - Original Message - From: Adam Young ayo...@redhat.com To: openstack-dev@lists.openstack.org Sent: Wednesday, 2 April, 2014 11:13:22 PM Subject: Re: [openstack-dev] [Keystone] python-keystoneclient v3 functionality On 04/01/2014 07:36 AM, Yaguang Tang wrote: Thanks Jamie, then the following question is do we intend to move other services client library V3 identity support to python-openstackclient? AFAIK it's poorly supported for Nova Cinder Neutron client library, and I am working on add v3 support for those libraries[1], just want to make sure that is the correct direction. [1] https://review.openstack.org/#/c/81749/ https://review.openstack.org/#/c/81767/ Sort of. The Keystone client should be responsible for all fo the service catalog manipulations throughout openstack. So the Cinder client should use the Keystone client. To see the idea, read Jamie's blog post: http://www.jamielennox.net/blog/2014/02/24/client-session-objects/ The main idea is that Keystone will handle the HTTP session setup, so that we have a single place to focus attention on for HTTP network security issues. And you should not need to parse the service catalog at all. So Adam is right in that the general idea to transition people to using the V3 API will be to use the keystoneclient.session.Session object and that will do everything for you. This is not going to be an easy transition for everyone and i've got a summit session proposed: http://summit.openstack.org/cfp/details/205 in which i want to deal with precisely this problem. Regarding your notion of openstackclient though, you need to seperate the concept of a CLI and the library. Take for example Heat or Horizon, they communicate with keystone through the python-keystoneclient and nova via the python-novaclient etc. They do not use the keystone or nova cli utility. The primary job of the python-*client libraries is NOT to provide a cli. The cli is just an application that makes use of the library. Yeah, but when we talking about the support of v3 for Nova Cinder and Neutron. I think it's mostly about the auth token middleware and CLI support of the client library. So yes, i think it has generally been accepted that the clients will move (at there own pace) to using openstackclient for there CLI, but openstackclient will still rely on the various libraries to do the actual communication with services I wonder is it worth to enable v3 for CLI when we moving to openstackclient so that OpenStack users and operators can test and evaluate v3 API , and we may probably add a v3 test gate to CI. what we face is that user can use v3 API with novaclient CLI, this has been asked many times in the OpenStack user mailing list. Jamie 2014-04-01 12:08 GMT+08:00 Jamie Lennox jamielen...@redhat.com : On Tue, 2014-04-01 at 11:53 +0800, Yaguang Tang wrote: Hi all, I am sorry if this has been discussed before, the question is will we support keystone v3 operation in python-keystoneclient? I know most of the v3 functionality have been implemented in python-openstackclient, but from the python-openstackclient wiki says, it's primarily a wrapper of python-*client, and provides unified interface to user. The end user uses python-keystoneclient to manage user, tenant, service before, if we don't intend to support v3 functionality in keystoneclient, then it means we force end user to change from keystoneclient to openstackclient, is this what we want to do? It depends what you mean by python-keystoneclient. If you mean the python library then yes it supports the V3 API already. If you mean the keystone CLI that is currently bundled as part of the python-keystoneclient then yes that is deprecated in favour of python-openstackclient. We will maintain the CLI application in keystoneclient however even for V2 API calls I recommend that you use the openstack CLI tool. Jamie -- Tang Yaguang Canonical Ltd. | www.ubuntu.com | www.canonical.com Mobile: +86 152 1094 6968 gpg key: 0x187F664F ___ 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 -- Tang Yaguang Canonical Ltd. | www.ubuntu.com | www.canonical.com Mobile: +86 152 1094 6968 gpg key: 0x187F664F ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] Standing down as PTL
All hail the Mooball release. Now we just have to find a city that's in a state or country with a placename of Mooball - that shouldn't be too hard ... On 04/02/2014 08:20 PM, Qiming Teng wrote: Let's vote for the K, L, M release names now. :) Thanks, Steve. On Mon, Mar 31, 2014 at 11:22:49AM +1300, Steve Baker wrote: I don't intend to run for PTL for the Juno cycle; thankfully there are many Heat developers who would do a great job. Hopefully this wasn't a one-off though. I may run again for Kilmacow, Lacrosse or Mooball. cheers ___ 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] [heat] Standing down as PTL
On 03/04/14 16:03, Monty Taylor wrote: All hail the Mooball release. Now we just have to find a city that's in a state or country with a placename of Mooball - that shouldn't be too hard ... http://en.wikipedia.org/wiki/Mooball,_New_South_Wales On 04/02/2014 08:20 PM, Qiming Teng wrote: Let's vote for the K, L, M release names now. :) Thanks, Steve. On Mon, Mar 31, 2014 at 11:22:49AM +1300, Steve Baker wrote: I don't intend to run for PTL for the Juno cycle; thankfully there are many Heat developers who would do a great job. Hopefully this wasn't a one-off though. I may run again for Kilmacow, Lacrosse or Mooball. cheers ___ 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 -- Steve Wrong is endian little that knows everyone but. - Sam Hocevar ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] metadata for a HOT
Zane Bitter zbit...@redhat.com wrote on 04/02/2014 05:36:43 PM: I think that if you're going to propose a new feature, you should at least give us a clue who you think is going to use it and what for ;) I was not eager to do that yet because I have not found a fully satisfactory answer yet, at this point I am exploring options. But the problem I am thinking about is how Heat might connect to a holistic scheduler (a scheduler that makes a joint decision about a bunch of resources of various types). Such a scheduler needs input describing the things to be scheduled and the policies to apply in scheduling; the first half of that sounds a lot like a Heat template, so my thoughts go in that direction. But the HOT language today (since https://review.openstack.org/#/c/83758/ was merged) does not have a place to put policy that is not specific to a single resource. IIRC this has been discussed in the past and the justifications for including it in the template (as opposed to allowing metadata to be attached in the ReST API, as other projects already do for many things) were not compelling. I see that Keith Bray mentioned https://wiki.openstack.org/wiki/Heat/StackMetadata and https://wiki.openstack.org/wiki/Heat/UI in another reply on this thread. Are there additional places to look to find that discussion? I have also heard that there has been discussion of language extension issues. Is that a separate discussion and, if so, where can I read it? Thanks, Mike ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases. Data from Operators needed.
Stephen, Agree with you. Basically the page starts looking as requirements page. I think we need to move to google spreadsheet, where table is organized easily. Here's the doc that may do a better job for us: https://docs.google.com/spreadsheet/ccc?key=0Ar1FuMFYRhgadDVXZ25NM2NfbGtLTkR0TDFNUWJQUWcusp=sharing Thanks, Eugene. On Thu, Apr 3, 2014 at 5:34 AM, Prashanth Hari hvpr...@gmail.com wrote: More additions to the use cases ( https://wiki.openstack.org/wiki/Neutron/LBaaS/Usecases). I have updated some of the features we are interested in. Thanks, Prashanth On Wed, Apr 2, 2014 at 8:12 PM, Stephen Balukoff sbaluk...@bluebox.netwrote: Hi y'all-- Looking at the data in the page already, it looks more like a feature wishlist than actual usage data. I thought we agreed to provide data based on percentage usage of a given feature, the end result of the data collection being that it would become more obvious which features are the most relevant to the most users, and therefore are more worthwhile targets for software development. Specifically, I was expecting to see something like the following (using hypothetical numbers of course, and where technical people from Company A etc. fill out the data for their organization): == L7 features == Company A (Cloud operator serving external customers): 56% of load-balancer instances use Company B (Cloud operator serving external customers): 92% of load-balancer instances use Company C (Fortune 100 company serving internal customers): 0% of load-balancer instances use == SSL termination == Company A (Cloud operator serving external customers): 95% of load-balancer instances use Company B (Cloud operator serving external customers): 20% of load-balancer instances use Company C (Fortune 100 company serving internal customers): 50% of load-balancer instances use. == Racing stripes == Company A (Cloud operator serving external customers): 100% of load-balancer instances use Company B (Cloud operator serving external customers): 100% of load-balancer instances use Company C (Fortune 100 company serving internal customers): 100% of load-balancer instances use In my mind, a wish-list of features is only going to be relevant to this discussion if (after we agree on what the items under consideration ought to be) each technical representative presents a prioritized list for their organization. :/ A wish-list is great for brain-storming what ought to be added, but is less relevant for prioritization. In light of last week's meeting, it seems useful to list the features most recently discussed in that meeting and on the mailing list as being points on which we want to gather actual usage data (ie. from what people are actually using on the load balancers in their organization right now). Should we start a new page that lists actual usage percentages, or just re-vamp the one above? (After all, wish-list can be useful for discovering things we're missing, especially if we get people new to the discussion to add their $0.02.) Thanks, Stephen On Wed, Apr 2, 2014 at 3:46 PM, Jorge Miramontes jorge.miramon...@rackspace.com wrote: Thanks Eugene, I added our data onto the requirements page since I was hoping to prioritize requirements based on the operator data that gets provided. We can move it over to the other page if you think that makes sense. See everyone on the weekly meeting tomorrow! Cheers, --Jorge From: Susanne Balle sleipnir...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, April 1, 2014 4:09 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] Load balancing use cases. Data from Operators needed. I added two more. I am still working on our HA use cases. Susanne On Tue, Apr 1, 2014 at 4:16 PM, Fox, Kevin M kevin@pnnl.gov wrote: I added our priorities. I hope its formatted well enough. I just took a stab in the dark. Thanks, Kevin -- *From:* Eugene Nikanorov [enikano...@mirantis.com] *Sent:* Tuesday, April 01, 2014 3:02 AM *To:* OpenStack Development Mailing List *Subject:* [openstack-dev] [Neutron][LBaaS] Load balancing use cases. Data from Operators needed. Hi folks, On the last meeting we decided to collect usage data so we could prioritize features and see what is demanded most. Here's the blank page to do that (in a free form). I'll structure it once we have some data. https://wiki.openstack.org/wiki/Neutron/LBaaS/Usecases Please fill with the data you have. Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev
