Re: [openstack-dev] [Solum] Command Line Interface for Solum
I have updated the blueprint for this feature, and approved the direction for the v0.1 milestone: https://blueprints.launchpad.net/solum/+spec/command-line The specification for the CLI is not intended to be complete at this stage. It only specified what I expect we will need for v0.1. Additional commands can be added as we add support for additional features in subsequent releases. Adrian On Nov 15, 2013, at 12:00 PM, Doug Hellmann doug.hellm...@dreamhost.commailto:doug.hellm...@dreamhost.com wrote: On Thu, Nov 14, 2013 at 2:28 AM, Adrian Otto adrian.o...@rackspace.commailto:adrian.o...@rackspace.com wrote: Doug, On Nov 13, 2013, at 9:28 AM, Doug Hellmann doug.hellm...@dreamhost.commailto:doug.hellm...@dreamhost.com wrote: On Sun, Nov 10, 2013 at 10:15 AM, Noorul Islam K M noo...@noorul.commailto:noo...@noorul.com wrote: Hello all, I registered a new blueprint [1] for command line client interface for Solum. We need to decide whether we should have a separate repository for this or go with new unified CLI framework [2]. Since Solum is not part of OpenStack I think it is not the right time to go with the unified CLI. One of the key features of the cliff framework used for the unified command line app is that the subcommands can be installed independently of the main program. So you can write plugins that work with the openstack client, but put them in the solum client library package (and source repository). That would let you, for example: $ pip install python-solumclient $ pip install python-openstackclient $ openstack solum make me a paas Dean has done a lot of work to design a consistent noun-followed-by-verb command structure, so please look at that work when picking subcommand names (for example, you shouldn't use solum as a prefix as I did in my example above, since we are removing the project names from the commands). Are you referring to openstack solum … in your suggestion of what not to do? If there is no project name in there, how would it work? Would we have a flat global namespace for all verbs? I could imagine the following verb/noun combinations off the bat: deploy app list assemblies list plans list services get assembly assembly_name|uri get plan plan_name|uri get service service_name|uri scale assembly assembly_name|uri (+|-n) resize du assembly_name|uri start assembly stop assembly delete assembly delete app What about using combined noun+verb combinations, so you would end up with commands like: deploy_app …etc. That might be more specific and require less processing logic. There is a namespace for the nouns, and each noun has a namespace with verbs. So you might say openstack app deploy, openstack assembly show, etc. Placing the noun first lets us use tab completion to help the user figure out what options they have (openstack assembly tab would show scale, resize, start, and stop as completion options). As far as processing logic, that's all handled by the framework already. The commands are registered as multi-word names pointing to a single class, and cliff figures out which one to run based on the input command line. Doug Thanks, Adrian Doug ___ 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.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] [qa] moratorium on new negative tests in Tempest
Great work! Now the test cases in Tempest are well-stocked so it's a good time to rearrange the design of test codes. I checked mailing lists, IRC log and etherpads relating to this topic. Let me leave my 5 thoughts below. How to handle: 1. Data type (e.g, int, bool) 2. Specific value or format support (e.g, RegExp) 3. Boundary value analysis (David made a mention to this issue below) 4. Invalid value by non-Unicode (Ken'ichi made a mention in his mail Nov 13) 5. Errors that complicated pre- or post- processings are required for reproducing them I suggest that issues 1-4 be considered in the scope of new framework. From above sources, I feel a little bias towards invalid value testing. On the other hand, I think that some tests remain outside of this framework. As for Swift, the max total size of sending HTTP headers for metadata is 4096 bytes but the max size of meta-key is 128 bytes and the max of meta-value is 256 bytes. It might be difficult to test boundary value of total HTTP headers with the new framework. In such cases, is it OK to write test case like current implementation? Anyway, I do never want to derail this work. I am looking forward to a prototype:) Best Regards, Daisuke Morita Excerpts from David Kranz's message of 2013-11-12 14:33:04 -0500: I am working on this with Marc Koderer but we only just started and are not quite ready. But since you asked now... The problem is that the current implementation of negative tests is that each case is represented as code in a method and targets a particular set of api arguments and expected result. In most (but not all) of these tests there is boilerplate code surrounding the real content which is the actual arguments being passed and the value expected. That boilerplate code has to be written correctly and reviewed. The general form of the solution has to be worked out but basically would involve expressing these tests declaratively, perhaps in a yaml file. In order to do this we will need some kind of json schema for each api. The main implementation around this is defining the yaml attributes that make it easy to express the test cases, and somehow coming up with the json schema for each api. In addition, we would like to support fuzz testing where arguments are, at least partially, randomly generated and the return values are only examined for 4xx vs something else. This would be possible if we had json schemas. The main work is to write a generator and methods for creating bad values including boundary conditions for types with ranges. I had thought a bit about this last year and poked around for an existing framework. I didn't find anything that seemed to make the job much easier but if any one knows of such a thing (python, hopefully) please let me know. The negative tests for each api would be some combination of declaratively specified cases and auto-generated ones. With regard to the json schema, there have been various attempts at this in the past, including some ideas of how wsme/pecan will help, and it might be helpful to have more project coordination. I can see a few options: 1. Tempest keeps its own json schema data 2. Each project keeps its own json schema in a way that supports automated extraction 3. There are several use cases for json schema like this and it gets stored in some openstacky place that is not in tempest So that is the starting point. Comments and suggestions welcome! Marc and I just started working on an etherpad https://etherpad.openstack.org/p/bp_negative_tests but any one is welcome to contribute there. -David -- Daisuke Morita morita.dais...@lab.ntt.co.jp NTT Software Innovation Center, NTT Corporation ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] A droidstack(android on top of openstack) powered by qemu - some thoughts and implementation
Dear list, This year I was working on the idea of building an android cloud on top of openstack. I call it it droidstack hereby. A typical usage could be using android apps without downloading them. For example, playing 3d games remotely. The implementation is thought to be consisted of featured qemu, a featured android, several featured client applications and a featured openstack. What has been done is the qemu, android, and client part. But the integration with openstack is never got the priority and time to be implemented. Here I'd like to spread out the idea and what has been implemented. So people wants to do similar things could reuse the work had been done. Here is the qemu link: https://github.com/hudayou/qemu Please use the 161 branch, the implemented features includes: Android simulator opengles feature Tigervnc low latency extension(http://sourceforge.net/apps/mediawiki/tigervnc/index.php?title=VNC_Latency_Considerations) Here is the vnc client(and android app) link: https://github.com/hudayou/turbo Please use the turbo branch, the implemented features include: QEMU sound extension Turbovnc rfb protocol layer integration Any thoughts? Best Regards, Hengqing Hu ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [All] [Climate]Where should we define Exceptions ?
Hi, Declaring Exceptions in Openstack projects is quite straightforward and identical for most of the projects : all of them are defined in a global exception.py module called each time a specific exception must be handled. I recently received a -1 for that, so I would like to come back to the community and ask if a global exceptions file should still be the good way of doing, or not. What are your thoughts ? -Sylvain ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder][Glance] OSLO update
On 21/11/13 16:14 -0500, Doug Hellmann wrote: So I would really appreciate any comments or pieces of advice. Is it sufficient to include just the short form of the original commit message, along with the commit id in the oslo-incubator repository for reference? I've done this and alse seen it being done by others. In most of the cases, using the commit message title is enough. However, if the sync is intended to fix a bug or introduces more relevant changes, it is definitely useful to have that expressed in the commit message. FF -- @flaper87 Flavio Percoco pgpLu2NRP0IXZ.pgp Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Infrastructure ]Support for PCI Passthrough
Hi, We add the new feature of PCI passthrough in Nova enables assigning a PCI device to an instance in openstack. Now we want to add integration tests in Temptest to cover our module. We come up with several ideas like fade device or QEMU IOMMU emulator, but they are not possible. We talk to people in Nova and they suggest us to contact you to find a better solution. Our module only works on the compute node that enables VT-d and contains special PCIs which support the SR-IOV. So is it possible to 1. setup compute node which enables pci passthrough. 2. modify the testing schedule logic allow the pci testing case be scheduled to that machine It would also be great if you have some other suggestions. Thanks a lot! Tan Here is the wiki of our work: https://wiki.openstack.org/wiki/Pci_passthrough#PCI_passthrough_use_notes Here is the wiki of our possible solution: https://wiki.openstack.org/wiki/PCI_passthrough_testing_frame_work_considration Best Regards, Tan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [All] [Climate]Where should we define Exceptions ?
On Fri, Nov 22 2013, Sylvain Bauza wrote: Declaring Exceptions in Openstack projects is quite straightforward and identical for most of the projects : all of them are defined in a global exception.py module called each time a specific exception must be handled. No. Ceilometer doesn't have any exception.py module for example, we don't plan to add one. Oslo had one and we deprecated it and have it removed from every project. Having a global exception file is bad idea most of the time, as it doesn't help to see what the exception relates to. -- Julien Danjou /* Free Software hacker * independent consultant 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
[openstack-dev] [Oslo] Improving oslo-incubator update.py
Greetings, Based on the recent discussion that came out about not having enough information in the commit message when syncing oslo-incubator modules, I was thinking that besides encouraging people to write better commit messages, we could also improve the script we use to sync those modules. Some of the changes that I've been thinking of: 1) Store the commit sha from which the module was copied from. Every project using oslo, currently keeps the list of modules it is using in `openstack-modules.conf` in a `module` parameter. We could store, along with the module name, the sha of the commit it was last synced from: module=log,commit or module=log log=commit 2) Add an 'auto-commit' parameter to the update script that will generate a commit message with the short log of the commits where the modules being updated were modified. Soemthing like: Syncing oslo-incubator modules log.py: commit1: short-message commit2: short-message commit3: short-message lockutils: commit4: short-message commit5: short-message #1 will help with figuring out when was the last time a module was updated and what changes have been introduced since then. #2 won't be the recommended way for writing commit messages. Oslo incubator syncs can have different side-effects in every project. However, it could be useful for trivial syncs. Thoughts? Cheers, FF -- @flaper87 Flavio Percoco pgpCmV9OwmxXq.pgp 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] How to stage client major releases in Gerrit?
Robert Collins wrote: I don't understand why branches would be needed here *if* the breaking changes don't impact any supported release of OpenStack. Right -- the trick is what does supported mean in that case. When the client libraries were first established as separate deliverables, they came up with a blanket statement that the latest version could always be used with *any* version of openstack you may have. The idea being, if some public cloud was still stuck in pre-diablo times, you could still use the same library to address both this public cloud and the one which was 2 weeks behind Havana HEAD. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to stage client major releases in Gerrit?
Mark Washenberger wrote: My question is, is there a correct way to stage breaking changes in Gerrit? Has some other team already dealt with this problem? [...] It sounds like a case where we could use a feature branch. There have been a number of them in the past when people wanted to incrementally work on new features without affecting master, and at first glance (haha) it sounds appropriate here. As a quick sidebar, what does a feature branch entail in today's parlance? It can be created on request by release management members (or infra-core team). I /think/ that by default it would get tested against master in other branches. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Introducing the new OpenStack service for Containers
Tim Bell wrote: Can we make sure that the costs for the end users are also considered as part of this ? - Configuration management will need further modules - Dashboard confusion as we get multiple tabs - Accounting, Block Storage, Networking, Orchestration confusion as the concepts diverge Is this really a good idea to create another project considering the needs of the whole openstack community ? Personally, it will have to prove a really different API and set of use cases to justify the cost of a separate project. I'm waiting to see what they come up with, but IMHO it's compute in both cases. We've seen with the libvirt-sandbox discussion that using technology (hypervisor vs. container) to draw the line between the use cases is a bit over-simplifying the problem. I don't really want us to create a container service and end up implementing the same hypervisor backends than in Nova, just because hypervisors can perfectly also be used to serve lightweight application-centric workloads. Or the other way around (keep Docker support in Nova since you can perfectly run an OS in a container). At first glance, extending the Nova API to also cover lightweight app-centric use cases would avoid a ton of duplication... If the main concern is to keep Nova small and manageable, I'd rather rip out pieces like nova-network or the scheduler, which are clearly not compute. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging
Russell Bryant wrote: [...] I'm not thrilled about the prospect of this going into a new project for multiple reasons. - Given the priority and how long this has been dragging out, having to wait for a new project to make its way into OpenStack is not very appealing. - A new project needs to be able to stand on its own legs. It needs to have a reasonably sized development team to make it sustainable. Is this big enough for that? Having it in Barbican (and maybe have Barbican join under the identity program) would mitigate the second issue. But the first issue stands, and I share your concerns. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime
Great initiative! I would certainly be interested taking part in this -- although I wouldn't necessary claim to be among people with the know-how to design and implement it well. For sure this is going to be a painful but exciting process. Regards, Alex From: Robert Collins robe...@robertcollins.net To: OpenStack Development Mailing List openstack-dev@lists.openstack.org, Date: 21/11/2013 11:00 PM Subject:[openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime https://etherpad.openstack.org/p/icehouse-external-scheduler I'm looking for 4-5 folk who have: - modest Nova skills - time to follow a fairly mechanical (but careful and detailed work needed) plan to break the status quo around scheduler extraction And of course, discussion galore about the idea :) Cheers, 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Search Project - summit follow up
Dmitri, If you intend to make this middleware generic and reusable between different OpenStack services, your best shot, to my understanding, will be to propose a new library in oslo-incubator. -- Best regards, Oleg Gelbukh On Fri, Nov 22, 2013 at 4:05 AM, Dmitri Zimin(e) | StackStorm d...@stackstorm.com wrote: On Wed, Nov 20, 2013 at 2:11 PM, Dolph Mathews dolph.math...@gmail.comwrote: On Wed, Nov 20, 2013 at 1:06 PM, Dmitri Zimin(e) | StackStorm d...@stackstorm.com wrote: Thanks Terry for highlighting this: Yes, tenant isolation is the must. It's not reflected in the prototype - it queries Solr directly; but the proper implementation will go through the query API service, where ACL will be applied. UX folks are welcome to comment on expected queries. I think the key benefit of cross-resource index over querying DBs is that it saves the clients from implementing complex queries case by case, leaving flexibility to the user. I question the need for this service, as this service **should** very much be dependent on the clients for this functionality. Expecting to query backends directly must be a misunderstanding somewhere... Start with a specification for filtering across all services and advocate for it on both existing and new APIs. Dolph, thanks for the suggestion: we will begin drafting the API on the wiki. Just to be clear: this is not filtering. Existing filtering APIs are [getting] sufficient. This is a full text search, which doesn't exist yet. SWIFT is now considering Search API, ideologically similar, but limited to Object Storage metadata [1]. Search middleware can make it generic and extensible. And yes, middleware may be a better term, as this is not a service like nova or cinder, but a layer on top. Do we need to clarify where search middleware shall live? Or do we question wether there is the need for search functionality? What else shall we do to make the discussion forward? [1] http://lists.openstack.org/pipermail/openstack-dev/2013-November/019014.html -- Dmitri. On Wed, Nov 20, 2013 at 2:27 AM, Thierry Carrez thie...@openstack.orgwrote: Dmitri Zimin(e) | StackStorm wrote: Hi Stackers, The project Search is a service providing fast full-text search for resources across OpenStack services. [...] At first glance this looks slightly scary from a security / tenant isolation perspective. Most search results would be extremely user-specific (and leaking data from one user to another would be catastrophic), so the benefits of indexing (vs. querying DB) would be very limited ? -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -Dolph ___ 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] [horizon] Javascript development improvement
I will start reading documentation in order to integrate node in development, we also want to integrate its testing into the existing ones. I think a blueprint will be necessary. - Original Message - From: Jiri Tomasek jtoma...@redhat.com To: openstack-dev@lists.openstack.org Sent: Thursday, November 21, 2013 1:55:48 PM Subject: Re: [openstack-dev] [horizon] Javascript development improvement Hi, I also don't see an issue with using nodejs in Horizon development environment. Is the problem in Django not differentiating the development and production environments by default? Could the problem be resolved by having two different environments with the two requirements files etc. similar as Rails does? Regarding less, I don't really care what compiler we use as long as it works. And if we need to provide uncompiled less for production, then let's use Lesscpy. Jirka On 11/21/2013 09:21 AM, Ladislav Smola wrote: Hello, as long as node won't be Production dependency, it shouldn't be a problem, right? I give +1 to that Regards Ladislav On 11/20/2013 05:01 PM, Maxime Vidori wrote: Hi all, I know it is pretty annoying but I have to resurrect this subject. With the integration of Angularjs into Horizon we will encounter a lot of issues with javascript. I ask you to reconsider to bring back Nodejs as a development platform. I am not talking about production, we are all agree that Node is not ready for production, and we do not want it as a backend. But the facts are that we need a lot of its features, which will increase the tests and the development. Currently, we do not have any javascript code quality: jslint is a great tool and can be used easily into node. Angularjs also provides end-to-end testing based on nodejs again, testing is important especially if we start to put more logic into JS. Selenium is used just to run qUnit tests, we can bring back these tests into node and have a clean unified testing platform. Tests will be easier to perform. Finally, (do not punch me in the face) lessc which is used for bootstrap is completely integrated into it. I am afraid that modern javascript development can not be perform without this tool. Regards Maxime Vidori ___ 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] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime
I'd very much like to take part in the discussions. Depending on the outcome of said discussion, I may or may not want to participate in the implementation :) Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ 2013/11/21 Robert Collins robe...@robertcollins.net: https://etherpad.openstack.org/p/icehouse-external-scheduler I'm looking for 4-5 folk who have: - modest Nova skills - time to follow a fairly mechanical (but careful and detailed work needed) plan to break the status quo around scheduler extraction And of course, discussion galore about the idea :) Cheers, 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] future fate of nova-network?
On Fri, Nov 15, 2013 at 2:21 PM, Russell Bryant rbry...@redhat.com wrote: In particular, has there been a decision made about whether it will definitely be deprecated in some (as yet unspecified) future release, or whether it will continue to be supported for the foreseeable future? We want to deprecate it. There are some things blocking moving forward with this. In short: 1) Feature parity (primarily something that satisfies performance and HA requirements addressed by nova-network in multi-host mode) 2) Testing and quality parity. The status of Neutron testing in the gate is far inferior to the testing done against nova-network. I'm personally more worried about #2 than #1 at this point. A major issue is that very few people actually stepped up and agreed to help with #2 at the summit [2]. Only one person signed up to work on tempest issues. Nobody signed up to help with grenade. If this doesn't happen, nova-network can't be deprecated, IMO. If significant progress isn't made ASAP this cycle, and ideally by mid-cycle so we can change directions if necessary, then we'll have to discuss what next step to take. That may include un-freezing nova-network so that various people holding on to enhancements to nova-network can start submitting them back. It's a last resort, but I consider it on the table. Another approach to help with (1) is in Icehouse we remove the features from nova-network that neutron does not implement. We have warned about deprecation for a good few releases, so its almost OK. But that somewhat assumes (2) is still going well. John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] V3 API Review Checklist and style guide
On 19 November 2013 11:40, Christopher Yeoh cbky...@gmail.com wrote: I've updated the Nova review check list with some details for reviewing V3 API changesets and started a bit of a style guide for the API. Checklist: https://wiki.openstack.org/w/index.php?title=ReviewChecklist#Nova_Review_Checklist Looks good, but should we mention what we can change after Icehouse, when we bump the extension version. Obviously, that detail should also go in the docs. I wonder if we should rename all the core extensions to start with os- for consistency? Makes it easier to expand/contact what is in core at a later date without changing the API format. Style Guide: https://wiki.openstack.org/wiki/Nova/APIStyleGuide Awesome. Only thing I see missing is a list of the error codes we use, and how we use them. John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Javascript development improvement
Maxime Vidori maxime.vid...@enovance.com wrote: Hi all, I know it is pretty annoying but I have to resurrect this subject. With the integration of Angularjs into Horizon we will encounter a lot of issues with javascript. I ask you to reconsider to bring back Nodejs as a development platform. I am not talking about production, we are all agree that Node is not ready for production, and we do not want it as a backend. But the facts are that we need a lot of its features, which will increase the tests and the development. Currently, we do not have any javascript code quality: jslint is a great tool and can be used easily into node. Angularjs also provides end-to-end testing based on nodejs again, testing is important especially if we start to put more logic into JS. Selenium is used just to run qUnit tests, we can bring back these tests into node and have a clean unified testing platform. Tests will be easier to perform. It seems a bit crazy to me to introduce NodeJS as a dependency just for the sake of an easy way to run jslint. There are other options available that run without NodeJS as a dependency. There are more implications to running NodeJS even only for development. It will likely have an impact on our infrastructure as well, since we'll want these checks running on patches up for review. Then if it's there for development it increases the risk it will creep in as a dependency for our runtime. As for Selenium, are you talking about rewriting our existing Selenium tests in Javascript? If so I am opposed to this. The strength of our community is in Python, if we want to encourage people to write more tests we should make it easy for them to do so. I think you bring up great points, we do need to control our Javascript quality better especially as we bring in more of it into our codebase. But, style checks, CSS, and unit testing, shouldn't require NodeJS. Julie Finally, (do not punch me in the face) lessc which is used for bootstrap is completely integrated into it. I am afraid that modern javascript development can not be perform without this tool. Regards Maxime Vidori ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Swift] Server Side Encryption
Gregory Holt z-launch...@brim.net wrote on 20/11/2013 05:46:41 PM: From: Gregory Holt z-launch...@brim.net To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, Date: 20/11/2013 05:49 PM Subject: Re: [openstack-dev] [Swift] Server Side Encryption On Nov 20, 2013, at 5:26 AM, David Hadas dav...@il.ibm.com wrote: Hi all, We created a wiki page discussing the addition of software side encryption to Swift: The general scheme is to create a swift proxy middleware that will encrypt and sign the object data during PUT and check the signature + decrypt it during GET. The target is to create two domains - the user domain between the client and the middleware where the data is decrypted and the system domain between the middleware and the data at rest (on the device) where the data is encrypted. Design goals include: (1) Extend swift as necessary but without changing existing swift behaviors and APIs; (2) Support encrypting data incoming from unchanged clients See: https://wiki.openstack.org/wiki/Swift/server-side-enc We would like to invite feedback. I'll bite, though I'm fairly sure I already know the response. Why all this complexity for what amounts to just encrypting data on disk in case the disk is stolen, lost, or reused? That's the only protection I see this providing and it would seem it could be achieved with a single cluster key stored only on the Swift proxy servers. All the rest seems like gyrations that provide no true additional benefit. If a client actually cares about having their data encrypted, they should encrypt it themselves and only they would keep the key. A couple of reasons: -- improve re-keying by having a hierarchy -- finer grain control on encryption, e.g., per account (the objective is not just to protect against disks walking away). No argument, best security is client side encryption. This said, there seems to be a need for tenant-controlled, server side encryption, based both upon what is offered by other services and discussions I have had with users. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Javascript development improvement
On 11/21/2013 01:55 PM, Jiri Tomasek wrote: Hi, Regarding less, I don't really care what compiler we use as long as it works. And if we need to provide uncompiled less for production, then let's use Lesscpy. There is at least one bug open against Ubuntu[1], asking to install python-lesscpy as well, as customers often need to re-create or change stylesheets. This would imply nodejs in a production environment, when going back to less. Just naming the n word here, makes people bite, for whatever reason ;-) Matthias [1] https://bugs.launchpad.net/ubuntu/+source/openstack-dashboard/+bug/1071276 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Javascript development improvement
On 11/22/2013 11:10 AM, Maxime Vidori wrote: I will start reading documentation in order to integrate node in development, we also want to integrate its testing into the existing ones. I think a blueprint will be necessary. Since it was such a pain to get rid of nodejs, I'd love to see other options here. Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder][Glance] OSLO update
But what if I want to update some module that consists of ten or even more files (like rpc or db) and each of these files has quite a long change log? In that case the commit message may turn out to be really long even if only commit ids and names are included. On Wed, Nov 20, 2013 at 12:37 PM, Elena Ezhova eezh...@mirantis.com wrote: 20.11.2013, 06:18, John Griffith john.griff...@solidfire.com: On Mon, Nov 18, 2013 at 3:53 PM, Mark McLoughlin mar...@redhat.com wrote: On Mon, 2013-11-18 at 17:24 +, Duncan Thomas wrote: Random OSLO updates with no list of what changed, what got fixed etc are unlikely to get review attention - doing such a review is extremely difficult. I was -2ing them and asking for more info, but they keep popping up. I'm really not sure what the best way of updating from OSLO is, but this isn't it. Best practice is to include a list of changes being synced, for example: https://review.openstack.org/54660 Every so often, we throw around ideas for automating the generation of this changes list - e.g. cinder would have the oslo-incubator commit ID for each module stored in a file in git to tell us when it was last synced. Mark. _ __ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Been away on vacation so I'm afraid I'm a bit late on this... but; I think the point Duncan is bringing up here is that there are some VERY large and significant patches coming from OSLO pulls. The DB patch in particular being over 1K lines of code to a critical portion of the code is a bit unnerving to try and do a review on. I realize that there's a level of trust that goes with the work that's done in OSLO and synchronizing those changes across the projects, but I think a few key concerns here are: 1. Doing huge pulls from OSLO like the DB patch here are nearly impossible to thoroughly review and test. Over time we learn a lot about real usage scenarios and the database and tweak things as we go, so seeing a patch set like this show up is always a bit unnerving and frankly nobody is overly excited to review it. 2. Given a certain level of *trust* for the work that folks do on the OSLO side in submitting these patches and new additions, I think some of the responsibility on the review of the code falls on the OSLO team. That being said there is still the issue of how these changes will impact projects *other* than Nova which I think is sometimes neglected. There have been a number of OSLO synchs pushed to Cinder that fail gating jobs, some get fixed, some get abandoned, but in either case it shows that there wasn't any testing done with projects other than Nova (PLEASE note, I'm not referring to this particular round of patches or calling any patch set out, just stating a historical fact). 3. We need better documentation in commit messages explaining why the changes are necessary and what they do for us. I'm sorry but in my opinion the answer it's the latest in OSLO and Nova already has it is not enough of an answer in my opinion. The patches mentioned in this thread in my opinion met the minimum requirements because they at least reference the OSLO commit which is great. In addition I'd like to see something to address any discovered issues or testing done with the specific projects these changes are being synced to. I'm in no way saying I don't want Cinder to play nice with the common code or to get in line with the way other projects do things but I am saying that I think we have a ways to go in terms of better communication here and in terms of OSLO code actually keeping in mind the entire OpenStack eco-system as opposed to just changes that were needed/updated in Nova. Cinder in particular went through some pretty massive DB re-factoring and changes during Havana and there was a lot of really good work there but it didn't come without a cost and the benefits were examined and weighed pretty heavily. I also think that some times the indirection introduced by adding some of the openstack.common code is unnecessary and in some cases makes things more difficult than they should be. I'm just not sure that we always do a very good ROI investigation or risk assessment on changes, and that opinion applies to ALL changes in OpenStack projects, not OSLO specific or anything else. All of that being said, a couple of those syncs on the list are outdated. We should start by doing a fresh pull for these and if possible add some better documentation in the commit messages as to the justification for the patches that would be great. We can take a closer look at the changes and the history behind them and try to get some review progress made here. Mark mentioned some good ideas regarding capturing commit ID's from synchronization pulls and I'd like to
Re: [openstack-dev] [nova][heat][[keystone] RFC: introducing request identification
On Tue, 19 Nov 2013 12:03:57 -0500 Adam Young ayo...@redhat.com wrote: On 11/19/2013 08:21 AM, Dolph Mathews wrote: Related BP: Create a unified request identifier https://blueprints.launchpad.net/nova/+spec/cross-service-request-id I interested in cross-service-request-id because it has potential to solve several problem. I believe that API-retry would improve reliability of processing especially in HA environment. But it has fundamental problem what POST methods isn't idempotent. In my understand, currently, a lot of OpenStack API caller doesn't API-retry to avoid problem when do POST and response was lost. For reference: https://wiki.openstack.org/wiki/Support-retry-with-idempotency I think id has to be something passed in by the client is essential part of to solve that problem. And I recently found that cross-service-request-id could realize that objective. It is really nice idea. I understand, currently cross-service-request-id's objective is for debugging. It is very useful. In addition, I think that cross-service-request-id can use for ensuring POST idempotent. If the service received known cross-service-request-id, the service just return existence resource-id to clients. And the service don't create new resource. I understand it's need several considerations. (Please refer the thread of [Heat]Updated summit etherpad: API-retry-with-idempotency) However, basically it's good function for reliability. What do you think about it? And we have discussed workplans as well, which would be data to be carried along with the request id https://blueprints.launchpad.net/keystone/+spec/delegation-workplans https://etherpad.openstack.org/keystone_workplans On Tue, Nov 19, 2013 at 5:04 AM, haruka tanizawa harube...@gmail.com mailto:harube...@gmail.com wrote: Hi stackers!! I'd like to ask for your opinions about my idea of identifying request. Challenges == We have no way to know the final result of an API request. Indeed we can continuously get the status of allocated resources, but this is just resource status, not request status. It doesn't matter so much for manual operations. But it does for automated clients like heat. We need request-oriented-status and it should be disclosed to clients. Literally, we need to address two items for it. 1. how to identify request from clients 2. how to disclose status of request to clients Note that this email includes only 1 for initiating the discussion. Also, bp:instance-tasks-api[0] should include both two items above. Proposal: introducing request identification = I'd like to introduce request identification, which is disclosed to clients. There are two characteristics: - request identification is unique ID for each request so that we can identify tell a specific request from others. - request identification is available for clients so that we can enable any after-request-operations like check, retry[1] or cancel[2]. (of course we need to add more logic for check/retry/cancel, but I'm pretty sure that indentifying request is the starting point for these features) In my understandings, main objections should be 'who should generate and maintain such IDs?'. How to implement request identification = There are several options at least. (See also recent discussion at openstack-dev[3]) 1. Enable user to provide his/her own request identification within API request. This should be the simplest way. But providing id from outside looks hard to be accepted. For example, Idempotency for OpenStack API[4]. Or instance-tasks-api enable to user to put his/her own request identification. 2. Use correlation_id in oslo as request identification. correlation_id looks similar concept of request indentification, but correlation_id in nova was already rejected[5]. 3. Enable keystone to generate request identification (we can call it 'request-token', for example). Before sending actual API request to nova-api, client sends a request to keystone to get 'request-token'. -2 Then client sends an actual API request with 'request-token'. Nova-api will consult it to keystone whether it was really generated. Sounds like a auth-token generated by keystone, differences are: [lifecycle] auth-token is used for multiple API requests before it expires, 'request-token' is used for only single API request. [reusing] if the same 'request-token' was specified twice or more times, nova-api simply returns 20x (works like
Re: [openstack-dev] [nova] future fate of nova-network?
2013/11/22 John Garbutt j...@johngarbutt.com: Another approach to help with (1) is in Icehouse we remove the features from nova-network that neutron does not implement. We have warned about deprecation for a good few releases, so its almost OK. You want to motivate Neutron developers by punishing users of nova-network who are probably already nervous that the rug will be pulled out from under them? I'm about a -1,000,000 on that one. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] future fate of nova-network?
On Fri, Nov 22, 2013 at 11:25:51AM +, John Garbutt wrote: On Fri, Nov 15, 2013 at 2:21 PM, Russell Bryant rbry...@redhat.com wrote: In particular, has there been a decision made about whether it will definitely be deprecated in some (as yet unspecified) future release, or whether it will continue to be supported for the foreseeable future? We want to deprecate it. There are some things blocking moving forward with this. In short: 1) Feature parity (primarily something that satisfies performance and HA requirements addressed by nova-network in multi-host mode) 2) Testing and quality parity. The status of Neutron testing in the gate is far inferior to the testing done against nova-network. I'm personally more worried about #2 than #1 at this point. A major issue is that very few people actually stepped up and agreed to help with #2 at the summit [2]. Only one person signed up to work on tempest issues. Nobody signed up to help with grenade. If this doesn't happen, nova-network can't be deprecated, IMO. If significant progress isn't made ASAP this cycle, and ideally by mid-cycle so we can change directions if necessary, then we'll have to discuss what next step to take. That may include un-freezing nova-network so that various people holding on to enhancements to nova-network can start submitting them back. It's a last resort, but I consider it on the table. Another approach to help with (1) is in Icehouse we remove the features from nova-network that neutron does not implement. We have warned about deprecation for a good few releases, so its almost OK. We deprecated it on the basis that users would be able to do a upgrade to new release providing something that was feature equivalent. We didn't deprecate it on the basis that we were going to remove the feature and provide no upgrade path, leaving users screwed. So I don't consider removing features from nova-network to be an acceptable approach, until they exist in Neutron or something else that users can upgrade their existing deployments to. 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
Re: [openstack-dev] [horizon] Javascript development improvement
On Friday 22 November 2013 13:13:29 Matthias Runge wrote: On 11/21/2013 01:55 PM, Jiri Tomasek wrote: Hi, Regarding less, I don't really care what compiler we use as long as it works. And if we need to provide uncompiled less for production, then let's use Lesscpy. There is at least one bug open against Ubuntu[1], asking to install python-lesscpy as well, as customers often need to re-create or change stylesheets. I asked chuck months ago to package it :-) This would imply nodejs in a production environment, when going back to less. Just naming the n word here, makes people bite, for whatever reason ;-) Matthias [1] https://bugs.launchpad.net/ubuntu/+source/openstack-dashboard/+bug/1071276 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) signature.asc Description: This is a digitally signed message part. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Javascript development improvement
There is at least one bug open against Ubuntu[1], asking to install python-lesscpy as well, as customers often need to re-create or change stylesheets. This would imply nodejs in a production environment, when going back to less. As long as the css will be the only one included into the package, we cannot run into this issue. If someone wants to modify the less file he could compile it and just copy paste the result into the proper directory. It seems a bit crazy to me to introduce NodeJS as a dependency just for the sake of an easy way to run jslint. There are other options available that run without NodeJS as a dependency. Sadly, the only solutions which try to implement jslint in pure python are in alpha or abandoned. If you have a python library which has the same quality as jslint (which is written by Douglas Crockford himself), I will be glad to take a look at it. There are more implications to running NodeJS even only for development. It will likely have an impact on our infrastructure as well, since we'll want these checks running on patches up for review. Then if it's there for development it increases the risk it will creep in as a dependency for our runtime. That is a good point, but Selenium also provides external dependencies, like a browser to run into. I do not really know the infrastructure used by jenkins and how we can integrate our solution into, but I do not think it is impossible (I have never got any trouble with the installation of node with the sources in any distro). As for Selenium, are you talking about rewriting our existing Selenium tests in Javascript? If so I am opposed to this. The strength of our community is in Python, if we want to encourage people to write more tests we should make it easy for them to do so. Currently we have two Selenium tests in pure python, and all the others are running in a page with qUnit, which is a javascript unit testing framework. Lastly, we will start using angularjs as a front-end framework, it provides an advanced testing framework which allows us to get rid of selenium. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] future fate of nova-network?
On 11/22/2013 04:47 AM, Daniel P. Berrange wrote: On Fri, Nov 22, 2013 at 11:25:51AM +, John Garbutt wrote: On Fri, Nov 15, 2013 at 2:21 PM, Russell Bryant rbry...@redhat.com wrote: In particular, has there been a decision made about whether it will definitely be deprecated in some (as yet unspecified) future release, or whether it will continue to be supported for the foreseeable future? We want to deprecate it. There are some things blocking moving forward with this. In short: 1) Feature parity (primarily something that satisfies performance and HA requirements addressed by nova-network in multi-host mode) 2) Testing and quality parity. The status of Neutron testing in the gate is far inferior to the testing done against nova-network. I'm personally more worried about #2 than #1 at this point. A major issue is that very few people actually stepped up and agreed to help with #2 at the summit [2]. Only one person signed up to work on tempest issues. Nobody signed up to help with grenade. If this doesn't happen, nova-network can't be deprecated, IMO. If significant progress isn't made ASAP this cycle, and ideally by mid-cycle so we can change directions if necessary, then we'll have to discuss what next step to take. That may include un-freezing nova-network so that various people holding on to enhancements to nova-network can start submitting them back. It's a last resort, but I consider it on the table. Another approach to help with (1) is in Icehouse we remove the features from nova-network that neutron does not implement. We have warned about deprecation for a good few releases, so its almost OK. We deprecated it on the basis that users would be able to do a upgrade to new release providing something that was feature equivalent. We didn't deprecate it on the basis that we were going to remove the feature and provide no upgrade path, leaving users screwed. So I don't consider removing features from nova-network to be an acceptable approach, until they exist in Neutron or something else that users can upgrade their existing deployments to. 100% agree. -1 on removing nova-network features that people may very well be using in production, successfully. -Sean -- Sean Dague http://dague.net 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] [horizon] Javascript development improvement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/22/2013 02:19 PM, Sascha Peilicke wrote: On Friday 22 November 2013 13:13:29 Matthias Runge wrote: On 11/21/2013 01:55 PM, Jiri Tomasek wrote: Hi, Regarding less, I don't really care what compiler we use as long as it works. And if we need to provide uncompiled less for production, then let's use Lesscpy. There is at least one bug open against Ubuntu[1], asking to install python-lesscpy as well, as customers often need to re-create or change stylesheets. I asked chuck months ago to package it :-) AFAIK it is packaged already. I was not speaking about lesscpy (which might raised your attention here), but about less compiler in general (or other tools, probably useful for maintainers/customizers tasks). Matthias -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSj2qnAAoJEOnz8qQwcaIWeZcH/jC7RUTUPD+fa9lG92YmYuoU XiG9xivEVtOrhHlqigb43A6rGVkq7IPEVCnf3nMCwxtVHcoLdy3Pq8QPqFEI9LNv GrjfoKoFy8R71AuAWVblTWgMxJ/4ffHDny4na4FDiqn02vMCucYvsPAKsNU6m3fU SaFC1pH0f7/LeVpa13IJuM7XlEKpbPNwKObFfxalIen9ISP+9iQeWlczAr96Z198 tjdPg+2CeXM4Dh+jklYjOQHB5ITxFI3U4ehXCDB+aJS5HnGulL4gF1120zsBScG7 fsTI67n+r0mhMo9rIQdVVJFmK/wpHXzKQi8bsBJctk+hJ1UG9sHNjRJVmmq9SWY= =7B9B -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][LBaaS] Subteam meeting on Thursday, 21
Meeting logs from the latest meeting: Minutes: http://eavesdrop.openstack.org/meetings/neutron_lbaas/2013/neutron_lbaas.2013-11-21-14.00.html Minutes (text): http://eavesdrop.openstack.org/meetings/neutron_lbaas/2013/neutron_lbaas.2013-11-21-14.00.txt Log: http://eavesdrop.openstack.org/meetings/neutron_lbaas/2013/neutron_lbaas.2013-11-21-14.00.log.html Thanks, Eugene. On Thu, Nov 21, 2013 at 3:04 PM, Eugene Nikanorov enikano...@mirantis.comwrote: Meeting reminder! Today, 14-00 UTC, #openstack-meeting Agenda for the meeting: 1) Announcements 2) Progress with qa and third-party testing 3) Feature design discussions Thanks, Eugene. On Tue, Nov 19, 2013 at 12:30 PM, Eugene Nikanorov enikano...@mirantis.com wrote: Hi folks, Let's meet on #openstack-meeting on Thrsday, 21, at 14-00 UTC We'll discuss current progress and design of some of proposed features. Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to stage client major releases in Gerrit?
On Fri, Nov 22, 2013 at 3:31 AM, Thierry Carrez thie...@openstack.orgwrote: Robert Collins wrote: I don't understand why branches would be needed here *if* the breaking changes don't impact any supported release of OpenStack. Right -- the trick is what does supported mean in that case. When the client libraries were first established as separate deliverables, they came up with a blanket statement that the latest version could always be used with *any* version of openstack you may have. The idea being, if some public cloud was still stuck in pre-diablo times, you could still use the same library to address both this public cloud and the one which was 2 weeks behind Havana HEAD. I'm curious about the historical circumstance of this requirement -- were the services supported master, minus two releases at the time? We're not testing more than two stable releases against the latest clients in CI today, so I find it odd that we still bother with this claim, without demonstrating that it's true. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Oslo] Improving oslo-incubator update.py
On 2013-11-22 03:11, Flavio Percoco wrote: Greetings, Based on the recent discussion that came out about not having enough information in the commit message when syncing oslo-incubator modules, I was thinking that besides encouraging people to write better commit messages, we could also improve the script we use to sync those modules. Some of the changes that I've been thinking of: 1) Store the commit sha from which the module was copied from. Every project using oslo, currently keeps the list of modules it is using in `openstack-modules.conf` in a `module` parameter. We could store, along with the module name, the sha of the commit it was last synced from: module=log,commit or module=log log=commit 2) Add an 'auto-commit' parameter to the update script that will generate a commit message with the short log of the commits where the modules being updated were modified. Soemthing like: Syncing oslo-incubator modules log.py: commit1: short-message commit2: short-message commit3: short-message lockutils: commit4: short-message commit5: short-message #1 will help with figuring out when was the last time a module was updated and what changes have been introduced since then. #2 won't be the recommended way for writing commit messages. Oslo incubator syncs can have different side-effects in every project. However, it could be useful for trivial syncs. Thoughts? +1. I've been thinking along the same lines. I always try to include the git oneline output in my Oslo syncs anyway, but it's not trivial to figure out the appropriate ones to include so doing it automatically would be fantastic. One other thought I had was to add the ability to split one Oslo sync up into multiple commits, either one per module, or even one per Oslo commit for some really large module changes (I'm thinking of the 1000 line db sync someone mentioned recently). It would be more review churn, but at least it would keep the changes per review down to a more reasonable level. I'm not positive it would be beneficial, but I thought I'd mention it. -Ben ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Javascript development improvement
On 11/22/2013 02:49 PM, Maxime Vidori wrote: It seems a bit crazy to me to introduce NodeJS as a dependency just for the sake of an easy way to run jslint. There are other options available that run without NodeJS as a dependency. Sadly, the only solutions which try to implement jslint in pure python are in alpha or abandoned. If you have a python library which has the same quality as jslint (which is written by Douglas Crockford himself), I will be glad to take a look at it. There's a jslint fork called jshint which is able to run in the browser without any node.js dependency. I created a POC patch [1] long time ago to demonstrate its capabilities. It's integrated with qunit and runs automatically with the horizon test suite. The patch also contains a .jshintrc file for the node.js package but you can remove it since it's not used by the qunit+jshint test at all. Imre [1] 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
[openstack-dev] [Neutron][LBaaS] L7 rules design
Hi Avishay, lbaas folks, I've reviewed the wiki and have some questions/suggestions: 1) Looks like L7Policy is lacking 'name' attribute in it's description. However i see little benefit of having a name for this object 2) lbaas-related neutron client commands start with lb-, please fix this. 3) How does L7Policy specifies relation of vip and pool? 4) How default pool will be associated with the vip? Will it be a l7 rule of special kind? It is not quite clear what does mean associating vip with pool with policy if each rule in the policy contains 'SelectedPool' attribute. 5) what is 'action'? What other actions except SELECT_POOL can be? In fact my suggestion will be slightly different: - Instead of having L7Policy which i believe serves only to rules grouping, we introduce VipPoolAssociation as follows: VipPoolAssociation id, vip_id, pool_id, default - boolean flag for default pool for the vip L7Rule then will have vippoolassociation_id (it's better to shorten the attr name) just like it has policy_id in your proposal. L7Rule doesn't need SelectedPool attribute since once it attached to VipPoolAssociation, the rule then points to the pool with pool_id of that association. In other words, VipPoolAssociation is almost the same as L7Policy but named closer to it's primary goal of associating vips and pools. I would also suggest to add add/delete-rule operation for the association. What do you think? Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] FreeBSD hypervisor (bhyve) driver
Russell, First, thank you for the whiteboard input regarding the blueprint for FreeBSD hypervisor nova driver: https://blueprints.launchpad.net/nova/+spec/freebsd-compute-node We were considering libvirt support for bhyve hypervisor as well, only wouldn't want to do this as the first approach for FreeBSD+OpenStack integration. We'd rather bring bhyve bindings for libvirt later as another integration option. For FreeBSD host support a native hypervisor driver is important and desired long-term and we would like to have it anyways. Among things to consider are the following: - libvirt package is additional (non-OpenStack), external dependency (maintained in the 'ports' collection, not included in base system), while native API (via libvmmapi.so library) is integral part of the base system. - libvirt license is LGPL, which might be an important aspect for some users. Rafal ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] FreeBSD hypervisor (bhyve) driver
On 11/22/2013 10:43 AM, Rafał Jaworowski wrote: Russell, First, thank you for the whiteboard input regarding the blueprint for FreeBSD hypervisor nova driver: https://blueprints.launchpad.net/nova/+spec/freebsd-compute-node We were considering libvirt support for bhyve hypervisor as well, only wouldn't want to do this as the first approach for FreeBSD+OpenStack integration. We'd rather bring bhyve bindings for libvirt later as another integration option. For FreeBSD host support a native hypervisor driver is important and desired long-term and we would like to have it anyways. Among things to consider are the following: - libvirt package is additional (non-OpenStack), external dependency (maintained in the 'ports' collection, not included in base system), while native API (via libvmmapi.so library) is integral part of the base system. - libvirt license is LGPL, which might be an important aspect for some users. That's perfectly fine if you want to go that route as a first step. However, that doesn't mean it's appropriate for merging into Nova. Unless there are strong technical justifications for why this approach should be taken, I would probably turn down this driver until you were able to go the libvirt route. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Introducing the new OpenStack service for Containers
On Thu, Nov 21, 2013 at 11:07 AM, Tim Bell tim.b...@cern.ch wrote: Can we make sure that the costs for the end users are also considered as part of this ? - Configuration management will need further modules - Dashboard confusion as we get multiple tabs - Accounting, Block Storage, Networking, Orchestration confusion as the concepts diverge Is this really a good idea to create another project considering the needs of the whole openstack community ? Hi Tim, We have not made the determination that a new service is necessary yet. All the discussion today will be about is to see what the differences are. After we have that, we will go back to discuss with Nova team and see if the split is even necessary. --kr Tim ___ 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] Introducing the new OpenStack service for Containers
On Thu, Nov 21, 2013 at 9:58 AM, Sam Alba sam.a...@gmail.com wrote: On Thu, Nov 21, 2013 at 9:39 AM, Krishna Raman kra...@gmail.com wrote: On Thu, Nov 21, 2013 at 8:57 AM, Sam Alba sam.a...@gmail.com wrote: I wish we can make a decision during this meeting. Is it confirmed for Friday 9am pacific? Friday 9am Pacific seems to be the best time for this meeting. Can we use the #openstack-meeting channel for this? If not, then I can find another channel. For the agenda, I propose - going through https://etherpad.openstack.org/p/containers-service-apiand understand capabilities of all container technologies + would like the experts on each of those technologies to fill us in - go over the API proposal and see what we need to change. I think it's too early to go through the API. Let's first go through all options discussed before to support containers in openstack compute: #1 Have this new compute service for containers (other than Nova) #2 Extend Nova virt API to support containers #3 Support containers API as a third API for Nova Depending how it goes, then it makes sense to do an overview of the API I think. What do you guys think? Will go over the options on the table briefly today. As we discussed during the design session, it will be important to figure out the delta between Nova VM API and what is required for containers. After we have the delta, we can decide on which of those 3 options makes sense. --kr On Thu, Nov 21, 2013 at 8:24 AM, Chuck Short chuck.sh...@canonical.com wrote: Hi Has a decision happened when this meeting is going to take place, assuming it is still taking place tomorrow. Regards chuck On Mon, Nov 18, 2013 at 7:58 PM, Krishna Raman kra...@gmail.com wrote: On Nov 18, 2013, at 4:30 PM, Russell Bryant rbry...@redhat.com wrote: On 11/18/2013 06:30 PM, Dan Smith wrote: Not having been at the summit (maybe the next one), could somebody give a really short explanation as to why it needs to be a separate service? It sounds like it should fit within the Nova area. It is, after all, just another hypervisor type, or so it seems. But it's not just another hypervisor. If all you want from your containers is lightweight VMs, then nova is a reasonable place to put that (and it's there right now). If, however, you want to expose the complex and flexible attributes of a container, such as being able to overlap filesystems, have fine-grained control over what is shared with the host OS, look at the processes within a container, etc, then nova ends up needing quite a bit of change to support that. I think the overwhelming majority of folks in the room, after discussing it, agreed that Nova is infrastructure and containers is more of a platform thing. Making it a separate service lets us define a mechanism to manage these that makes much more sense than treating them like VMs. Using Nova to deploy VMs that run this service is the right approach, IMHO. Clayton put it very well, I think: If the thing you want to deploy has a kernel, then you need Nova. If your thing runs on a kernel, you want $new_service_name. I agree. Note that this is just another service under the compute project (or program, or whatever the correct terminology is this week). The Compute program is correct. That is established terminology as defined by the TC in the last cycle. So while distinct from Nova in terms of code, development should be tightly integrated until (and if at some point) it doesn't make sense. And it may share a whole bunch of the code. Another way to put this: The API requirements people have for containers include a number of features considered outside of the current scope of Nova (short version: Nova's scope stops before going *inside* the servers it creates, except file injection, which we plan to remove anyway). That presents a problem. A new service is one possible solution. My view of the outcome of the session was not it *will* be a new service. Instead, it was, we *think* it should be a new service, but let's do some more investigation to decide for sure. The action item from the session was to go off and come up with a proposal for what a new service would look like. In particular, we needed a proposal for what the API would look like. With that in hand, we need to come back and ask the question again of whether a new service is the right answer. I see 3 possible solutions here: 1) Expand the scope of Nova to include all of the things people want to be able to do with containers. This is my least favorite option. Nova is already really big. We've worked to split things out (Networking, Block Storage, Images) to keep it under control. I don't think a significant
Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime
I'm still a newbie here, so can not claim my Nova skills are even modest. But I'd like to track this, if nothing more. Thanks, Mike___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] future fate of nova-network?
To add to the screams of others removing features from nova-network to achieve parity with neutron is a non starter, and it rather scares me to hear it suggested. I do try not to rant in public, especially about things I'm not competent to really help fix, but I can't really contain this one any longer: rant As an operator I've moved my cloud neutron already, but while it provides many advanced features it still really falls down on providing simple solutions for simple use cases. Most operators I've talked to informally hate it for that and don't want to go near it and for new users, even those with advanced skill sets, neutron causes by far the most cursing and rage quits I've seen (again just my subjective observation) on IRC, Twitter, and the mailing lists. Providing feature parity and easy cut over *should have been* priority 1 when quantum split out of nova as it was for cinder (which was a delightful and completely unnoticable transition) We need feature parity and complexity parity with nova-network for the use cases it covers. The failure to do so or even have a reasonable plan to do so is currently the worst thing about openstack. /rant I do appreciate the work being done on advanced networking features in neutron, I'm even using some of them, just someone please bring focus back on the basics. -Jon ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder][Glance] OSLO update
On 22 November 2013 12:27, Elena Ezhova eezh...@mirantis.com wrote: But what if I want to update some module that consists of ten or even more files (like rpc or db) and each of these files has quite a long change log? In that case the commit message may turn out to be really long even if only commit ids and names are included. A message that is too long is definitely a better problem to have than a message that is missing important details. To turn the question round, how can a reviewer review a change that includes ten or even more files without any information on what changed and why? rpc and db are extremely difficult imports to review, and I've found problems in the last two I looked at. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] future fate of nova-network?
On 11/22/2013 11:17 AM, Jonathan Proulx wrote: To add to the screams of others removing features from nova-network to achieve parity with neutron is a non starter, and it rather scares me to hear it suggested. -1 from me too, so everyone can take a deep breath on this. :-) Providing feature parity and easy cut over *should have been* priority 1 when quantum split out of nova as it was for cinder (which was a delightful and completely unnoticable transition) +1 I think the experience with Neutron provides us some very good insight for future project splits/replacements. We're working on establishing more clear requirements for project incubation and graduation in the TC. One note I put down was that we should require that projects stay completely focused on being able to deprecate their replacement before adding *anything* else whenever possible. A good example is the current discussion around a new scheduling service. There have been lots of big ideas around this. Robert Collins just started a thread about a proposal to start this project but with a very strict scope of being able to replace nova-scheduler, and *nothing* more until that's completely done. I like that approach quite a bit. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Oslo] Improving oslo-incubator update.py
On 22 November 2013 14:59, Ben Nemec openst...@nemebean.com wrote: One other thought I had was to add the ability to split one Oslo sync up into multiple commits, either one per module, or even one per Oslo commit for some really large module changes (I'm thinking of the 1000 line db sync someone mentioned recently). It would be more review churn, but at least it would keep the changes per review down to a more reasonable level. I'm not positive it would be beneficial, but I thought I'd mention it. Cinder (often but not always me) tends to reject merges that do more that one module at a time, because it makes it far harder to review and spot problems, so some from of automation of this would be great. -- Duncan Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] future fate of nova-network?
On Fri, Nov 22, 2013 at 11:24:18AM -0500, Russell Bryant wrote: On 11/22/2013 11:17 AM, Jonathan Proulx wrote: To add to the screams of others removing features from nova-network to achieve parity with neutron is a non starter, and it rather scares me to hear it suggested. -1 from me too, so everyone can take a deep breath on this. :-) Providing feature parity and easy cut over *should have been* priority 1 when quantum split out of nova as it was for cinder (which was a delightful and completely unnoticable transition) +1 I think the experience with Neutron provides us some very good insight for future project splits/replacements. We're working on establishing more clear requirements for project incubation and graduation in the TC. One note I put down was that we should require that projects stay completely focused on being able to deprecate their replacement before adding *anything* else whenever possible. A good example is the current discussion around a new scheduling service. There have been lots of big ideas around this. Robert Collins just started a thread about a proposal to start this project but with a very strict scope of being able to replace nova-scheduler, and *nothing* more until that's completely done. I like that approach quite a bit. I'd suggest something even stronger. If we want to split out code into a new project, we should always follow the approach used for cinder. ie the existing fully functional code should be pulled out as is, and work then progress from there. That ensures we'd always have feature parity from the very start. Yes, you might have to then do a large amount of refactoring to get to where you want to be, but IMHO that's preferrable to starting something from scratch and forgetting to cover existing use cases. 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] [Solum] Working group on language packs
I have updated the language pack (name subject to change) blueprint with the outcomes from the face2face meetings, and drafted a specification that captures the discussion so far. The spec is centered around the core idea of transitioning base images into deployable images (that can be stored in Nova and sent to Glance). These are *DRAFT* and are intended for public debate. https://blueprints.launchpad.net/solum/+spec/lang-pack https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/BuildingSourceIntoDeploymentArtifacts Please take this opportunity to review these documents and offer criticism and critique via the ML - I will schedule a follow up deep dive for those who expressed interest in participation [1] after US Thanksgiving. [1] https://etherpad.openstack.org/p/SolumWorkshopTrack1Notes ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Introducing the new OpenStack service for Containers
Excerpts from Thierry Carrez's message of 2013-11-22 01:50:39 -0800: Tim Bell wrote: Can we make sure that the costs for the end users are also considered as part of this ? - Configuration management will need further modules - Dashboard confusion as we get multiple tabs - Accounting, Block Storage, Networking, Orchestration confusion as the concepts diverge Is this really a good idea to create another project considering the needs of the whole openstack community ? Personally, it will have to prove a really different API and set of use cases to justify the cost of a separate project. I'm waiting to see what they come up with, but IMHO it's compute in both cases. We've seen with the libvirt-sandbox discussion that using technology (hypervisor vs. container) to draw the line between the use cases is a bit over-simplifying the problem. Agreed, I think it has been over simplified, but that is what you do when you're not driven by a well understood real use-case, something I have yet to see from this discussion. I don't really want us to create a container service and end up implementing the same hypervisor backends than in Nova, just because hypervisors can perfectly also be used to serve lightweight application-centric workloads. Or the other way around (keep Docker support in Nova since you can perfectly run an OS in a container). At first glance, extending the Nova API to also cover lightweight app-centric use cases would avoid a ton of duplication... Agreed. There are a few weird things that come to mind though. One of those is that I imagine users would like to do something like this: host_id=$(container-thing allocate-host --flavor small appserver) db_id=$(container-thing allocate-host --flavor huge dbserver) app_id=$(container-thing run --host $host_id --image app-image) proxy_id=$(container-thing run --host $host_id --image proxy-image) cache_id=$(container-thing run --host $host_id --image cache-image) db_id=$(container-thing run --host $db_id) As in, they'd probably like to have VMs spun up and then chopped up into containers. If this is implemented first inside nova, that may end up being a rats nest and hard to separate later. The temptation to use private API's is really strong. But if it is outside nova, the separation stays clear and the two can be used without one-another very easily. If the main concern is to keep Nova small and manageable, I'd rather rip out pieces like nova-network or the scheduler, which are clearly not compute. Indeed, and those things are under way. :) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] future fate of nova-network?
Daniel P. Berrange berra...@redhat.com wrote on 11/22/2013 11:32:59 AM: A good example is the current discussion around a new scheduling service. There have been lots of big ideas around this. Robert Collins just started a thread about a proposal to start this project but with a very strict scope of being able to replace nova-scheduler, and *nothing* more until that's completely done. I like that approach quite a bit. I'd suggest something even stronger. If we want to split out code into a new project, we should always follow the approach used for cinder. ie the existing fully functional code should be pulled out as is, and work then progress from there. That ensures we'd always have feature parity from the very start. Yes, you might have to then do a large amount of refactoring to get to where you want to be, but IMHO that's preferrable to starting something from scratch and forgetting to cover existing use cases. I think that is what Robert is saying. Regards, Mike___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime
Dear all, I'm very interested in this subject as well. Actually there is also a discussion of the possibility of an independent scheduler in the mailisg list: http://lists.openstack.org/pipermail/openstack-dev/2013-November/019518.html Would it be possible to discuss about this subject in the next Scheduler meeting Nov 26th? Best regards, Toan - Original Message - From: Mike Spreitzer mspre...@us.ibm.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Friday, November 22, 2013 4:58:46 PM Subject: Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime I'm still a newbie here, so can not claim my Nova skills are even modest. But I'd like to track this, if nothing more. Thanks, Mike ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Javascript development improvement
Maxime Vidori maxime.vid...@enovance.com wrote: There is at least one bug open against Ubuntu[1], asking to install python-lesscpy as well, as customers often need to re-create or change stylesheets. This would imply nodejs in a production environment, when going back to less. As long as the css will be the only one included into the package, we cannot run into this issue. If someone wants to modify the less file he could compile it and just copy paste the result into the proper directory. This doesn't sound particularly friendly, I think what Matthias was getting at is that there are requests from users who want to be able to modify the CSS directly. It seems a bit crazy to me to introduce NodeJS as a dependency just for the sake of an easy way to run jslint. There are other options available that run without NodeJS as a dependency. Sadly, the only solutions which try to implement jslint in pure python are in alpha or abandoned. If you have a python library which has the same quality as jslint (which is written by Douglas Crockford himself), I will be glad to take a look at it. Sure, I'll look into it. There seems to be also Javascript-based solutions that could be viable. If anyone has recommendations based on past experience, please let me know. The patch Imre linked to looks like a good start! There are more implications to running NodeJS even only for development. It will likely have an impact on our infrastructure as well, since we'll want these checks running on patches up for review. Then if it's there for development it increases the risk it will creep in as a dependency for our runtime. That is a good point, but Selenium also provides external dependencies, like a browser to run into. I do not really know the infrastructure used by jenkins and how we can integrate our solution into, but I do not think it is impossible (I have never got any trouble with the installation of node with the sources in any distro). Selenium is already integrated with our Jenkins gate. I don't think it hurts either to run the tests in an environment similar to what they need to work in in the end. As for Selenium, are you talking about rewriting our existing Selenium tests in Javascript? If so I am opposed to this. The strength of our community is in Python, if we want to encourage people to write more tests we should make it easy for them to do so. Currently we have two Selenium tests in pure python, and all the others are running in a page with qUnit, which is a javascript unit testing framework. Lastly, we will start using angularjs as a front-end framework, it provides an advanced testing framework which allows us to get rid of selenium. I don't think Selenium is going away, and efforts have started around using it as well for our integration tests [0]. Looking at the current AngularJS patch up for review, it is testable without requiring NodeJS. From the initial mailing list discussion [1], my understanding is that we're planning on using a specific AngularJS feature, not rewriting everything with it. Changing our build system to accommodate this seems like getting a bit ahead of ourselves. Julie [0] https://blueprints.launchpad.net/horizon/+spec/selenium-integration-testing [1] http://lists.openstack.org/pipermail/openstack-dev/2013-November/018850.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Javascript development improvement
Imre Farkas ifar...@redhat.com wrote: On 11/22/2013 02:49 PM, Maxime Vidori wrote: It seems a bit crazy to me to introduce NodeJS as a dependency just for the sake of an easy way to run jslint. There are other options available that run without NodeJS as a dependency. Sadly, the only solutions which try to implement jslint in pure python are in alpha or abandoned. If you have a python library which has the same quality as jslint (which is written by Douglas Crockford himself), I will be glad to take a look at it. There's a jslint fork called jshint which is able to run in the browser without any node.js dependency. I created a POC patch [1] long time ago to demonstrate its capabilities. It's integrated with qunit and runs automatically with the horizon test suite. Thanks Imre, this is interesting. Would you mind restoring the patch? If you don't have time to work on it please indicate so (I don't think it's possible to pick up a patch if the status is 'Abandoned') and someone else can look into the test failures. The patch also contains a .jshintrc file for the node.js package but you can remove it since it's not used by the qunit+jshint test at all. Sounds good. Julie Imre [1] 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] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging
On 11/21/13, 7:51 PM, Jamie Lennox jamielen...@redhat.com wrote: So i've a feeling that this was proposed and dismissed once before. I don't remember why. So my concern with barbican is that i'm under the impression that barbican was going to be an 'overcloud' service. That's a really bad way of putting it, but it is service and user facing and discovered via the service catalog. This feature will need to be configured at a lower level (runs in situations without a token) and so we will need to configure the services to point to an IP for the KDS service. Why would there be a need for token less authentication? My understanding of the feature is that each service account would have a KDS key associated with it. This means that each account would need to authenticate to Keystone before talking to Barbican. Are there service accounts that don’t have a keystone account? Is this an expected deployment of barbican (i can't see why not)? We certainly could enable this if needed. We already create separate uwsgi processes for the main and admin apis. We could create another one for the KDS. I’d rather not do that unless we have to though. Jarret Jamie On Thu, 2013-11-21 at 20:08 +, Jarret Raim wrote: The Barbican team has been taking a look at the KDS feature and the proposed patch and I think this may be better placed in Barbican rather than Keystone. The patch, from what I can tell, seems to require that a service account create use a key under its own tenant. In this use case, Barbican can handle the entire exchange and Keystone can just provide auth/auth for the process. This would allow for some great additional features including guaranteed entropy and additional security through the use of HSMs, auditing / logging, etc. Barbican is pretty far along at this point and it doesn¹t appear to be a huge amount of work to move the patch over as it doesn¹t seem to use any Keystone internals. What would people think about this approach? We¹re happy to help move the patch over and I¹m certainly happy to merge it as it feels like a good feature for barbican. Jarret On 11/21/13, 12:55 AM, Russell Bryant rbry...@redhat.com wrote: Greetings, I'd like to check in on the status of this API addition: https://review.openstack.org/#/c/40692/ The last comment is: propose against stackforge as discussed at summit? I don't see a session about this and from a quick look, don't see notes related to it in other session etherpads. When was this discussed? Can you summarize it? Last I heard, this was just being deferred to be merged early in Icehouse [1]. This is blocking one of the most important security features for OpenStack, IMO (trusted messaging) [2]. We've been talking about it for years. Someone has finally made some real progress on it and I feel like it has been given little to no attention. I'm not thrilled about the prospect of this going into a new project for multiple reasons. - Given the priority and how long this has been dragging out, having to wait for a new project to make its way into OpenStack is not very appealing. - A new project needs to be able to stand on its own legs. It needs to have a reasonably sized development team to make it sustainable. Is this big enough for that? What's the thinking on this? [1] http://lists.openstack.org/pipermail/openstack-dev/2013-August/013992.ht ml [2] https://review.openstack.org/#/c/37913/ -- 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 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] L3 advanced features blueprint mapping to IETF and IEEE standards
Nachi, I'm sorry to have missed this meeting. In my jet-lagged state, I somehow got it on my calendar for last night rather than last Tuesday night (my local time, MST). I have an interest in the dynamic routing area of neutron and I would like to be involved. Will this meeting be weekly? I'll go read through the meeting log. Carl Baldwin On Thu, Nov 7, 2013 at 11:18 PM, Nachi Ueno na...@ntti3.com wrote: Hi folks let's use #openstack-meeting on the meetings. I have also created an etherpad for this discussion (If you have any slide, please link to the page) https://etherpad.openstack.org/p/NeutronDynamicRoutingIceHouse Best Nachi 2013/11/8 Pedro Roque Marques pedro.r.marq...@gmail.com: What about an IRC meeting on this topic 11/19 at 9 p.m. PST ? This is 2 p.m in Japan and 6 a.m CET on the 20th. It is not ideal but i suspect we will have interest in participating from both Europe and Asia. I volunteer myself and Nachi Ueno na...@ntti3.com (the author of the BGP MPLS blueprint) as agenda organizers; please drop us a note if you intend to attend and wether you would like to present something to the group. Pedro. On Nov 7, 2013, at 11:27 AM, Rochelle.Grober rochelle.gro...@huawei.com wrote: From: Pedro Roque Marques [mailto:pedro.r.marq...@gmail.com] Colin, The nice thing about standards is that there are so many of them to choose from. For instance, if you take this Internet Draft: http://tools.ietf.org/html/draft-ietf-l3vpn-end-system-02 which is based on RFC4364. It has already been implemented as a Neutron plugin via OpenContrail (http://juniper.github.io/contrail-vnc/README.html); With this implementation each OpenStack cluster can be configured as its own Autonomous System. There is a blueprint https://blueprints.launchpad.net/neutron/+spec/neutron-bgp-mpls-vpn that is discussing adding the provisioning of the autonomous system and peering to Neutron. Please note that the work above does interoperate with 4364 using option B. Option C is possible but not that practical (as an operator you probably don't want to expose your internal topology between clusters). If you want to give it a try you can use this devstack fork: https://github.com/dsetia/devstack. You can use it to interoperate with a standard router that implements 4364 and support MPLS over GRE. Products from cisco/juniper/ALU/huwawei etc do. I believe that the work i'm referencing implements interoperability while having very minimal changes to Neutron. It is based on the same concept of neutron virtual network and it hides the BGP/MPLS functionality from the user by translating policies that establish connectivity between virtual networks into RFC 4364 concepts. Please refer to: https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron Would it make sense to have an IRC/Web meeting around interoperability with RFC4364 an OpenStack managed clusters ? I believe that there is a lot of work that has already been done there by multiple vendors as well as some carriers. +1 And it should be scheduled and announced a reasonable time in advance developers can plan to participate. --Rocky Pedro. On Nov 7, 2013, at 12:35 AM, Colin McNamara co...@2cups.com wrote: I have a couple concerns that I don’t feel I clearly communicated during the L3 advanced features session. I’d like to take this opportunity to both clearly communicate my thoughts, as well as start a discussion around them. Building to the edge of the autonomous system The current state of neutron implementation is functionally the l2 domain and simple l3 services that are part of a larger autonomous system. The routers and switches northbound of the OpenStack networking layer handled the abstraction and integration of the components. Note, I use the term “Autonomous System” to describe more then the notion of BGP AS, but more broadly in the term of a system that is controlled within a common framework and methodology, and integrates with a peer system that doesn’t not share that same scope or method of control These components that composed the autonomous system boundary implement protocols and standards that map into IETF and IEEE standards. The reasoning for this is interoperability. Before vendors utilize IETF for interoperability at this layer, the provider experience was horrible (this was my personal experience in the late 90’s). Wednesdays discussions in the Neutron Design Sessions A couple of the discussions, most notably the extension of l3 functionality fell within the scope of starting the process of extending Neutron with functionality that will result (eventually) in the ability for an OpenStack installation to operate as it’s own Autonomous System. The discussions that occurred to support L3 advanced functionality (northbound boundary), and the QOS extension functionality both fell into the scope of Northbound and Southbound boundaries
Re: [openstack-dev] [Cinder][Glance] OSLO update
On Fri, Nov 22, 2013 at 11:21 AM, Duncan Thomas duncan.tho...@gmail.comwrote: On 22 November 2013 12:27, Elena Ezhova eezh...@mirantis.com wrote: But what if I want to update some module that consists of ten or even more files (like rpc or db) and each of these files has quite a long change log? In that case the commit message may turn out to be really long even if only commit ids and names are included. A message that is too long is definitely a better problem to have than a message that is missing important details. If we are talking about merging only part of oslo into a consuming project, then we can't just keep track of the last revision that was merged, because that won't necessarily include all of the changes. Elena, were you planning to keep a separate revision for each entry under openstack/common (not every file, just the files and directories at that level)? To turn the question round, how can a reviewer review a change that includes ten or even more files without any information on what changed and why? rpc and db are extremely difficult imports to review, and I've found problems in the last two I looked at. Problems in the code, or in the way the code was merged? Doug ___ 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] [Oslo] Improving oslo-incubator update.py
On Fri, Nov 22, 2013 at 4:11 AM, Flavio Percoco fla...@redhat.com wrote: Greetings, Based on the recent discussion that came out about not having enough information in the commit message when syncing oslo-incubator modules, I was thinking that besides encouraging people to write better commit messages, we could also improve the script we use to sync those modules. Some of the changes that I've been thinking of: 1) Store the commit sha from which the module was copied from. Every project using oslo, currently keeps the list of modules it is using in `openstack-modules.conf` in a `module` parameter. We could store, along with the module name, the sha of the commit it was last synced from: module=log,commit or module=log log=commit The second form will be easier to manage. Humans edit the module field and the script will edit the others. 2) Add an 'auto-commit' parameter to the update script that will generate a commit message with the short log of the commits where the modules being updated were modified. Soemthing like: Syncing oslo-incubator modules log.py: commit1: short-message commit2: short-message commit3: short-message lockutils: commit4: short-message commit5: short-message #1 will help with figuring out when was the last time a module was updated and what changes have been introduced since then. #2 won't be the recommended way for writing commit messages. Oslo incubator syncs can have different side-effects in every project. However, it could be useful for trivial syncs. It looks like #2 would be a good way to start with commit messages, and just leave it up to the person doing the merge to add the why information. Doug Thoughts? Cheers, FF -- @flaper87 Flavio Percoco ___ 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] future fate of nova-network?
Starting from the existing code also makes migration for production environments currently using the code much easier. Support those of us running production OpenStack clouds needs to be one of the major development concerns as people reflect on refactoring along with making sure we don't make OpenStack more difficult to install/manage/configure. Tim -Original Message- From: Daniel P. Berrange [mailto:berra...@redhat.com] Sent: 22 November 2013 17:33 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] future fate of nova-network? On Fri, Nov 22, 2013 at 11:24:18AM -0500, Russell Bryant wrote: On 11/22/2013 11:17 AM, Jonathan Proulx wrote: To add to the screams of others removing features from nova-network to achieve parity with neutron is a non starter, and it rather scares me to hear it suggested. -1 from me too, so everyone can take a deep breath on this. :-) Providing feature parity and easy cut over *should have been* priority 1 when quantum split out of nova as it was for cinder (which was a delightful and completely unnoticable transition) +1 I think the experience with Neutron provides us some very good insight for future project splits/replacements. We're working on establishing more clear requirements for project incubation and graduation in the TC. One note I put down was that we should require that projects stay completely focused on being able to deprecate their replacement before adding *anything* else whenever possible. A good example is the current discussion around a new scheduling service. There have been lots of big ideas around this. Robert Collins just started a thread about a proposal to start this project but with a very strict scope of being able to replace nova-scheduler, and *nothing* more until that's completely done. I like that approach quite a bit. I'd suggest something even stronger. If we want to split out code into a new project, we should always follow the approach used for cinder. ie the existing fully functional code should be pulled out as is, and work then progress from there. That ensures we'd always have feature parity from the very start. Yes, you might have to then do a large amount of refactoring to get to where you want to be, but IMHO that's preferrable to starting something from scratch and forgetting to cover existing use cases. 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Oslo] Improving oslo-incubator update.py
On Fri, Nov 22, 2013 at 11:24 AM, Duncan Thomas duncan.tho...@gmail.comwrote: On 22 November 2013 14:59, Ben Nemec openst...@nemebean.com wrote: One other thought I had was to add the ability to split one Oslo sync up into multiple commits, either one per module, or even one per Oslo commit for some really large module changes (I'm thinking of the 1000 line db sync someone mentioned recently). It would be more review churn, but at least it would keep the changes per review down to a more reasonable level. I'm not positive it would be beneficial, but I thought I'd mention it. Cinder (often but not always me) tends to reject merges that do more that one module at a time, because it makes it far harder to review and spot problems, so some from of automation of this would be great. There are times when the commits are related, but in general this seems like a good practice. Doug -- Duncan Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] meaning of resource_id in a meter
On Thu, Nov 21, 2013 at 2:37 PM, Gordon Chung chu...@ca.ibm.com wrote: In all cases, these are free string fields. `user_id' and `project_id' map to Keystone _most of the time_, i'm sort of torn between the two -- which is why i brought it up i guess. i like the flexibility of having resource as a free string field but the difference between resource and project/user fields is that we can query directly on Resources. when we get a Resource, we get a list of associated Meters and if we don't set resource_id in a consistent manner, i worry we may be losing some relational information between Meters that groupings based off consistent resource_id can provide. The tuple (project id, source, resource id) is expected to be unique so that those values combined with a specific meter provide useful information about the resource. Beyond that unique constraint, I'm not sure we apply any rules, although check the SQL schema to make sure the resource id field isn't a short VARCHAR. Doug cheers, gordon chung openstack, ibm software standards email: chungg [at] ca.ibm.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] future fate of nova-network?
On Fri, Nov 22, 2013 at 12:39 PM, Tim Bell tim.b...@cern.ch wrote: Support those of us running production OpenStack clouds needs to be one of the major development concerns as people reflect on refactoring along with making sure we don't make OpenStack more difficult to install/manage/configure. To that end, I recommend posting questions like We're thinking of making large change 'X', how will that affect existing OpenStack deployments? to the openstack-operators mailing list. I know there are several OpenStack operators who don't subscribe to openstack or openstack-dev lists because of the enormous traffic volume. Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] RFC: Potential to increase min required libvirt version to 0.9.11 ?
On Wed, Nov 20, 2013 at 04:02:02PM +0100, Ralf Haferkamp wrote: On Wed, Nov 20, 2013 at 04:33:22PM +1300, Robert Collins wrote: On 20 November 2013 08:02, Daniel P. Berrange berra...@redhat.com wrote: Currently the Nova libvirt driver is declaring that it wants a minimum of libvirt 0.9.6. ... If there are other distros I've missed which expect to support deployment of Icehouse please add them to this list. Hopefully there won't be any with libvirt software older than Ubuntu 12.04 LTS The reason I'm asking this now, is that we're working to make the libvirt python module a separate tar.gz that can build with multiple libvirt versions, and I need to decide how ancient a libvirt we should support for it. Fantastic!!! The Ubuntu cloud archive https://wiki.ubuntu.com/ServerTeam/CloudArchive is how OpenStack is delivered by Canonical for Ubuntu LTS users. So I think you can go with e.g. 0.9.11 or even 0.9.12 depending on what the Suse folk say. I think 0.9.11 is fine for us. I am not worried too much about 0.9.12 either since openSUSE 12.2 (which has 0.9.11) will reach its EOL soon. I also added SLES to the table on: https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix Thanks, it looks like from the libvirt side, we are only going to be able to provide a standalone libvirt-python on PyPI that works back to version 0.9.11. Prior to 0.9.11 libvirt did not install its API description, which is a pre-requisite for the python bindings to build. Fortunately 0.9.11 lines up with all the distros we've got listed so far. 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
Re: [openstack-dev] [nova] future fate of nova-network?
On Fri, Nov 22, 2013 at 12:55:48PM -0500, Lorin Hochstein wrote: On Fri, Nov 22, 2013 at 12:39 PM, Tim Bell tim.b...@cern.ch wrote: Support those of us running production OpenStack clouds needs to be one of the major development concerns as people reflect on refactoring along with making sure we don't make OpenStack more difficult to install/manage/configure. To that end, I recommend posting questions like We're thinking of making large change 'X', how will that affect existing OpenStack deployments? to the openstack-operators mailing list. I know there are several OpenStack operators who don't subscribe to openstack or openstack-dev lists because of the enormous traffic volume. That's a good point, I should have asked that list about the proposal to increase the min required libvirt version too. I've posted to it now... 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
Re: [openstack-dev] [horizon] Javascript development improvement
On 22/11/13 12:06 -0500, Julie Pichon wrote: I don't think Selenium is going away, and efforts have started around using it as well for our integration tests [0]. Looking at the current AngularJS patch up for review, it is testable without requiring NodeJS. While the Angular modules are testable in QUnit, it would be a boon to use the testing patterns common with most Angular projects. It would make new developers, familiar with Angular but not Horizon, immediately familiar with the workflow. QUnit is acceptable, but karma/jasmine is preferable From the initial mailing list discussion [1], my understanding is that we're planning on using a specific AngularJS feature, not rewriting everything with it. Changing our build system to accommodate this seems like getting a bit ahead of ourselves. [1] http://lists.openstack.org/pipermail/openstack-dev/2013-November/018850.html To be clear, we're using a specific feature of Angular (the directive) to introduce it into the existing Django templates; that's not the only feature of Angular we're using. There are controllers services behind the directive, but using a directive is the cleanest way of integrating these features with the existing templates. -- Jordan O'Mara jomara at redhat.com Red Hat Engineering, Raleigh pgpVLkAm0WvI6.pgp 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] Introducing the new OpenStack service for Containers
On Fri, Nov 22, 2013 at 11:49 AM, Krishna Raman kra...@gmail.com wrote: Reminder: We are meting in about 15 minutes on #openstack-meeting channel. I wasn't able to make it. Was meeting-bot triggered? Is there a log of today's discussion? Thank you, Eric Windisch ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Keystone][Oslo] Future of Key Distribution Server, Trusted Messaging
On Fri, 2013-11-22 at 11:04 +0100, Thierry Carrez wrote: Russell Bryant wrote: [...] I'm not thrilled about the prospect of this going into a new project for multiple reasons. - Given the priority and how long this has been dragging out, having to wait for a new project to make its way into OpenStack is not very appealing. - A new project needs to be able to stand on its own legs. It needs to have a reasonably sized development team to make it sustainable. Is this big enough for that? Having it in Barbican (and maybe have Barbican join under the identity program) would mitigate the second issue. But the first issue stands, and I share your concerns. Yes, I agree. It's disappointing that this change of plans looks like its going to push out the ability of an OpenStack deployment to be secured. If this becomes a Barbican API, then we might be able to get the code working quickly ... but it will still be some time before Barbican is an integrated project, and so securing OpenStack will only be possible if you use this non-integrated project. Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime
I would definitely like to take part in this discussion and also contribute where I can. I was part of the scheduler sessions in the recent summit along with Debo Dutta, Gary Kotton, and Mike Spreitzer and we had proposed sessions on smart resource placement, and also the instance group API work for nova. We have been discussing this at our weekly scheduler meetings as well. I am also in the process of contributing a Solver Scheduler - a constraints-solver based way of finding optimal resource placements in openstack. In our smart resource placement proposal, we discussed a high level overview of scheduling considering cross services, and it hints at how the scheduler should sit outside as a separate service. But we decided to start within Nova first. This work of separating the scheduler is very promising, and I definitely would like to be involved in this effort. Thanks, Yathi. ‹ On 11/21/13, 12:58 PM, Robert Collins robe...@robertcollins.net wrote: https://etherpad.openstack.org/p/icehouse-external-scheduler I'm looking for 4-5 folk who have: - modest Nova skills - time to follow a fairly mechanical (but careful and detailed work needed) plan to break the status quo around scheduler extraction And of course, discussion galore about the idea :) Cheers, 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ironic][Cinder] Attaching Cinder volumes to baremetal instance
Hey guys, just starting out with Ironic, had a silly question. Can we attach bootable or non bootable plain cinder volumes during either provisioning of the baremetal instance or after provisioning the baremetal instance? I have seen a attach_volume method in the LibvirtVolumeDriver of the nova baremetal driver. So got curious. Thanks, Rohan Kanade ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Introducing the new OpenStack service for Containers
On Nov 22, 2013, at 10:26 AM, Eric Windisch e...@cloudscaling.com wrote: On Fri, Nov 22, 2013 at 11:49 AM, Krishna Raman kra...@gmail.com wrote: Reminder: We are meting in about 15 minutes on #openstack-meeting channel. I wasn't able to make it. Was meeting-bot triggered? Is there a log of today's discussion? Yes. Logs are here: http://eavesdrop.openstack.org/meetings/nova/2013/nova.2013-11-22-17.01.log.html Thank you, Eric Windisch ___ 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] [Infra] Support for PCI Passthrough
On 2013-11-22 08:59:16 + (+), Tan, Lin wrote: [...] Our module only works on the compute node that enables VT-d and contains special PCIs which support the SR-IOV. So is it possible to 1. setup compute node which enables pci passthrough. 2. modify the testing schedule logic allow the pci testing case be scheduled to that machine [...] If you're asking about our official test infrastructure for the OpenStack project, I believe this is infeasible for now. We currently perform testing within generic virtual machines provided by HPCloud and Rackspace, so the Nova compute nodes we build and test are already running under virtualization and in turn manage only paravirtualized QEMU instances. In the near term, your best bet is to run your own test infrastructure supporting the hardware features you require and report advisory results back on proposed changes: http://ci.openstack.org/third_party.html For a longer term solution, you may want to consult with the TripleO project with regards to their bare-metal test plan: https://wiki.openstack.org/wiki/TripleO/TripleOCloud -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [horizon] Javascript development improvement
That is a fact all client side development is based on javascript, Node allow us to easily execute javascript without a browser. Every time we will have a reflexion on the client side, Node will show up, what we are doing is just delaying something inevitable and wasting our forces in compromises. Node is not the best way, but it is the easiest one, what would we do next time, search another alternative in python, if it is buggy we will have to maintain it. You are right Node is currently fancy, but less is fancy, angular is fancy but they provides some ease and that is why we choose them. - Original Message - From: Jordan OMara jom...@redhat.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Friday, November 22, 2013 7:22:12 PM Subject: Re: [openstack-dev] [horizon] Javascript development improvement On 22/11/13 12:06 -0500, Julie Pichon wrote: I don't think Selenium is going away, and efforts have started around using it as well for our integration tests [0]. Looking at the current AngularJS patch up for review, it is testable without requiring NodeJS. While the Angular modules are testable in QUnit, it would be a boon to use the testing patterns common with most Angular projects. It would make new developers, familiar with Angular but not Horizon, immediately familiar with the workflow. QUnit is acceptable, but karma/jasmine is preferable From the initial mailing list discussion [1], my understanding is that we're planning on using a specific AngularJS feature, not rewriting everything with it. Changing our build system to accommodate this seems like getting a bit ahead of ourselves. [1] http://lists.openstack.org/pipermail/openstack-dev/2013-November/018850.html To be clear, we're using a specific feature of Angular (the directive) to introduce it into the existing Django templates; that's not the only feature of Angular we're using. There are controllers services behind the directive, but using a directive is the cleanest way of integrating these features with the existing templates. -- Jordan O'Mara jomara at redhat.com Red Hat Engineering, Raleigh ___ 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] RFC: Potential to increase min required libvirt version to 0.9.11 ?
On 2013-11-20 03:50:03 + (+), Tom Fifield wrote: Just confirming that the documentation for Ubuntu sets users up with the Cloud Archive. In Havana, Libvirt is 1.1.1 and qemu is 1.5.0. I've added a row to the table. There's a change currently up for review to (yet once more) try using Ubuntu Cloud Archive for the testing we perform on Ubuntu Precise (which is most of the testing we do as a project at the moment). https://review.openstack.org/48226 Unfortunately, the last time we tried we ran into a buggy version of libvirt there. https://launchpad.net/bugs/1228977 At the moment, we're still looking for confirmation that nova-compute no longer locks up with the latest libvirt in UCA (1.1.1). I'm going to run some manual tests, but anyone who can pitch in and confirm this bug is completely flushed out now would be most appreciated. I certainly don't want to introduce yet another nondeterministic bug into our integrated gate tests, especially after everything else we've been through in that regard this week. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] future fate of nova-network?
On 11/22/2013 12:55 PM, Lorin Hochstein wrote: On Fri, Nov 22, 2013 at 12:39 PM, Tim Bell tim.b...@cern.ch mailto:tim.b...@cern.ch wrote: Support those of us running production OpenStack clouds needs to be one of the major development concerns as people reflect on refactoring along with making sure we don't make OpenStack more difficult to install/manage/configure. To that end, I recommend posting questions like We're thinking of making large change 'X', how will that affect existing OpenStack deployments? to the openstack-operators mailing list. I know there are several OpenStack operators who don't subscribe to openstack or openstack-dev lists because of the enormous traffic volume. I honestly don't understand why openstack@ and openstack-operators@ are different lists. Perhaps openstack@ just needs better use of topic tagging ... -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Introducing the new OpenStack service for Containers
On 11/22/2013 02:29 PM, Krishna Raman wrote: On Nov 22, 2013, at 10:26 AM, Eric Windisch e...@cloudscaling.com mailto:e...@cloudscaling.com wrote: On Fri, Nov 22, 2013 at 11:49 AM, Krishna Raman kra...@gmail.com mailto:kra...@gmail.com wrote: Reminder: We are meting in about 15 minutes on #openstack-meeting channel. I wasn't able to make it. Was meeting-bot triggered? Is there a log of today's discussion? Yes. Logs are here: http://eavesdrop.openstack.org/meetings/nova/2013/nova.2013-11-22-17.01.log.html Yep, I used the 'nova' meeting topic for this one. If the meeting turns in to a regular thing, we should probably switch it to some sort of sub-team type name ... like nova-containers. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova] Proposal to add Matt Riedemann to nova-core
Greetings, I would like to propose adding Matt Riedemann to the nova-core review team. Matt has been involved with nova for a long time, taking on a wide range of tasks. He writes good code. He's very engaged with the development community. Most importantly, he provides good code reviews and has earned the trust of other members of the review team. https://review.openstack.org/#/dashboard/6873 https://review.openstack.org/#/q/owner:6873,n,z https://review.openstack.org/#/q/reviewer:6873,n,z Please respond with +1/-1, or any further comments. Thanks, -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Proposal to add Matt Riedemann to nova-core
+1 On Fri, Nov 22, 2013 at 12:53 PM, Russell Bryant rbry...@redhat.com wrote: Greetings, I would like to propose adding Matt Riedemann to the nova-core review team. Matt has been involved with nova for a long time, taking on a wide range of tasks. He writes good code. He's very engaged with the development community. Most importantly, he provides good code reviews and has earned the trust of other members of the review team. https://review.openstack.org/#/dashboard/6873 https://review.openstack.org/#/q/owner:6873,n,z https://review.openstack.org/#/q/reviewer:6873,n,z Please respond with +1/-1, or any further comments. Thanks, -- 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
Re: [openstack-dev] [Nova] Proposal to add Matt Riedemann to nova-core
Please respond with +1/-1, or any further comments. +1 from me -- Matt has been helping a lot lately. --Dan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to stage client major releases in Gerrit?
On 22 November 2013 22:31, Thierry Carrez thie...@openstack.org wrote: Robert Collins wrote: I don't understand why branches would be needed here *if* the breaking changes don't impact any supported release of OpenStack. Right -- the trick is what does supported mean in that case. When the client libraries were first established as separate deliverables, they came up with a blanket statement that the latest version could always be used with *any* version of openstack you may have. The idea being, if some public cloud was still stuck in pre-diablo times, you could still use the same library to address both this public cloud and the one which was 2 weeks behind Havana HEAD. Huh. There are two different directions we use the client in. Client install - cloud API (of arbitrary version A) Server install (of arbitrary version B) using the Python library - cloud API (version B) From a gating perspective I think we want to check that: - we can use the client against some set of cloud versions A - that some set of version B where servers running cloud version B can use the client against cloud version B But today we don't test against ancient versions of A or B. If we were to add tests for such scenarios, I'd strongly argue that we only add then for case A. Where we are using the client lib in an installed cloud, we don't need to test that it can still be used against pre-diablo etc: such installed clouds can keep using the old client lib. So assuming you agree with that assertion, where do we need a branch here? -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] [Nova] Proposal to add Matt Riedemann to nova-core
+1 On Sat, Nov 23, 2013 at 8:11 AM, Dan Smith d...@danplanet.com wrote: Please respond with +1/-1, or any further comments. +1 from me -- Matt has been helping a lot lately. --Dan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Proposal to add Matt Riedemann to nova-core
+1 On 11/22/13 at 03:53pm, Russell Bryant wrote: Greetings, I would like to propose adding Matt Riedemann to the nova-core review team. Matt has been involved with nova for a long time, taking on a wide range of tasks. He writes good code. He's very engaged with the development community. Most importantly, he provides good code reviews and has earned the trust of other members of the review team. https://review.openstack.org/#/dashboard/6873 https://review.openstack.org/#/q/owner:6873,n,z https://review.openstack.org/#/q/reviewer:6873,n,z Please respond with +1/-1, or any further comments. Thanks, -- 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
Re: [openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova
On Thursday, November 21, 2013 9:56:41 AM, Matt Riedemann wrote: On 11/3/2013 5:22 AM, Joe Gordon wrote: On Nov 1, 2013 6:46 PM, John Garbutt j...@johngarbutt.com mailto:j...@johngarbutt.com wrote: On 29 October 2013 16:11, Eddie Sheffield eddie.sheffi...@rackspace.com mailto:eddie.sheffi...@rackspace.com wrote: John Garbutt j...@johngarbutt.com mailto:j...@johngarbutt.com said: Going back to Joe's comment: Can both of these cases be covered by configuring the keystone catalog? +1 If both v1 and v2 are present, pick v2, otherwise just pick what is in the catalogue. That seems cool. Not quite sure how the multiple glance endpoints works in the keystone catalog, but should work I assume. We hard code nova right now, and so we probably want to keep that route too? Nova doesn't use the catalog from Keystone when talking to Glance. There is a config value glance_api_servers which defines a list of Glance servers that gets randomized and cycled through. I assume that's what you're referring to with we hard code nova. But currently there's nowhere in this path (internal nova to glance) where the keystone catalog is available. Yes. I was not very clear. I am proposing we change that. We could try shoehorn the multiple glance nodes in the keystone catalog, then cache that in the context, but maybe that doesn't make sense. This is a separate change really. FYI: We cache the cinder endpoints from keystone catalog in the context already. So doing something like that with glance won't be without president. But clearly, we can't drop the direct configuration of glance servers for some time either. I think some of the confusion may be that Glanceclient at the programmatic client level doesn't talk to keystone. That happens happens higher in the CLI level which doesn't come into play here. From: Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com On 10/17/2013 03:12 PM, Eddie Sheffield wrote: Might I propose a compromise? 1) For the VERY short term, keep the config value and get the change otherwise reviewed and hopefully accepted. 2) Immediately file two blueprints: - python-glanceclient - expose a way to discover available versions - nova - depends on the glanceclient bp and allowing autodiscovery of glance version and making the config value optional (tho not deprecated / removed) Supporting both seems reasonable. At least then *most* people don't need to worry about it and it just works, but the override is there if necessary, since multiple people seem to be expressing a desire to have it available. +1 Can we just do this all at once? Adding this to glanceclient doesn't seem like a huge task. I worry about us never getting the full solution, but it seems to have got complicated. The glanceclient side is done, as far as allowing access to the list of available API versions on a given server. It's getting Nova to use this info that's a bit sticky. Hmm, OK. Could we not just cache the detected version, to reduce the impact of that decision. On 28 October 2013 15:13, Eddie Sheffield eddie.sheffi...@rackspace.com mailto:eddie.sheffi...@rackspace.com wrote: So...I've been working on this some more and hit a bit of a snag. The Glanceclient change was easy, but I see now that doing this in nova will require a pretty huge change in the way things work. Currently, the API version is grabbed from the config value, the appropriate driver is instantiated, and calls go through that. The problem comes in that the actually glance server isn't communicated with until very late in the process. Nothing sees the servers at the level where the driver is determined. Also there isn't a single glance server but a list of them, and in the even of certain communication failures the list is cycled through until success or a number of retries has passed. So to change this to auto configuring will require turning this upside down, cycling through the servers at a higher level, choosing the appropriate driver for that server, and handling retries at that same level. Doable, but a much larger task than I first was thinking. Also, I don't really want the added overhead of getting the api versions before every call, so I'm thinking that going through the list of servers at startup and discovering the versions then and caching that somehow would be helpful as well. Thoughts? I do worry about that overhead. But with Joe's comment, does it not just boil down to caching the keystone catalog in the context? I am not a fan of all the specific talk to glance code we have in nova, moving more of that into glanceclient can only be a good thing. For the XenServer itegration, for efficiency reasons, we need glance to talk from dom0, so it has dom0 making the final HTTP call.
[openstack-dev] [OSSG][OSSN] Authenticated users are able to update passwords without providing their current password
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Authenticated users are able to update passwords without providing their current password - --- ### Summary ### An authenticated user is able to change their password without providing their current password. This allows compromised authentication tokens to be used to permanently compromise a user account. ### Affected Services / Software ### Horizon, Keystone, Identity, Grizzly ### Discussion ### Horizon allows a user to change their own password, which uses the Identity API to perform the password change. A user is required to supply their current password to successfully perform a password change. This requirement prevents a malicious user from stealing a user's authentication token and changing that user's password to permanently compromise their account. With this additional password check, a compromised authentication token only compromises the user account until the token is no longer valid due to expiration or revocation. When using the Identity v3 API, a user is able to successfully change their password without supplying the correct current password. This leaves users vulnerable to permanently compromised accounts if their authentication token is compromised. The Identity v2 API is not vulnerable to this issue, as it has a separate API call for updating user passwords that properly validates the current password. ### Recommended Actions ### In the OpenStack Grizzly release, a user is allowed to update the attributes in their own entry by default. It is recommended that you restrict user updates to only be allowed by admin users. This is done by setting the update_user policy to admin_required in Keystone's policy.json file. Here is an example snippet of a properly configured policy.json file: - begin example policy.json snippet identity:get_user: [[rule:admin_required]], identity:list_users: [[rule:admin_required]], identity:create_user: [[rule:admin_required]], identity:update_user: [[rule:admin_required]], identity:delete_user: [[rule:admin_required]], - end example policy.json snippet This change has the side-effect of restricting a user from updating any of their own attributes, not just their password. In the OpenStack Havana release, the default policy is to only allow admin users to update attributes in user entries. In addition, Horizon will not allow a user to change their own password if it is using the Identity v3 API, even if Keystone is configured to allow users to update their own entries. Despite this restriction in Horizon, it is recommended to leave the default update_user policy setting as is, as an attacker could target Keystone directly without using Horizon to initiate a password change. ### Contacts / References ### This OSSN : https://bugs.launchpad.net/ossn/+bug/1237989 Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1237989 OpenStack Security ML : openstack-secur...@lists.openstack.org OpenStack Security Group : https://launchpad.net/~openstack-ossg CVE: CVE-2013-4471 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSj9ZNAAoJEJa+6E7Ri+EVGLsH/1j3E6fiO/QInwO2bx7stVHN 27KWvP/8GcLzgNNYN9qMcJExCA5ZbmOXIJlzOR12x/7hrNMkShaaC+VQTYwInn0e TQ0AESwdb08Wv4GeFDOuc2sliYrH9JR5Lr8/kjGFsmSZ3O4Pyl4AGBrXUDehoVCZ rq3cSC9+utn11o+lY9BZigbufBCBdWHKKoJ93wEdnTkjl6cQAekqLJyTXLltR5x/ 7vSz4e0bYKLyKFZ5BLdPn2gR7pFfnjhlG+oZR0TwGYSCDLJeFFY5tkUKbc2hyGwi DqPp1escgHTDzXm2gUXWOHs8k0yitHq9JL62VXqL2lbWvbb/HJsCD87JUrFVLUo= =OLH1 -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] [Nova] Proposal to add Matt Riedemann to nova-core
On Fri, 2013-11-22 at 15:53 -0500, Russell Bryant wrote: Greetings, I would like to propose adding Matt Riedemann to the nova-core review team. Matt has been involved with nova for a long time, taking on a wide range of tasks. He writes good code. He's very engaged with the development community. Most importantly, he provides good code reviews and has earned the trust of other members of the review team. https://review.openstack.org/#/dashboard/6873 https://review.openstack.org/#/q/owner:6873,n,z https://review.openstack.org/#/q/reviewer:6873,n,z Please respond with +1/-1, or any further comments. +1, definitely a great addition to the team Mark. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime
De : Robert Collins [robe...@robertcollins.net] Date d'envoi : jeudi 21 novembre 2013 21:58 À : OpenStack Development Mailing List Objet : [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime https://etherpad.openstack.org/p/icehouse-external-scheduler I'm looking for 4-5 folk who have: - modest Nova skills - time to follow a fairly mechanical (but careful and detailed work needed) plan to break the status quo around scheduler extraction And of course, discussion galore about the idea :) Cheers, Rob Hi Rob, I can also add Climate as a separate Stackforge project which could get benefits from querying a scheduler service for electing some compute-hosts based on what we call a 'reservation request' [1] By the way, you mentioned the original BP for Climate [2] in the etherpad, which does let me thinking we are on the same page. That said, I would really love joining the team for delivering the new service, but unfortunately, I will only be able to commit myself on my personal spare time. Anyway, I'm following the discussion, whatever the outcome is. -Sylvain [1] https://etherpad.openstack.org/p/NovaIcehouse-ClimateInteractions [2] https://wiki.openstack.org/wiki/Blueprint-nova-planned-resource-reservation-api ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Solum] git-Integration working group
Hello all, I would like to kickoff the Git integration discussion. Goal of this subgroup is to go through the git-integration blueprint [1] and break it up into smaller blueprints that we can execute on. We have to consider 2 workflows: 1) For Milestone 1, pull based git workflow where user uses a public git repository (possibly on github) to trigger the build 2) For later milestones, a push based workflow where the git repository is maintained by Solum Devdatta has created 2 blueprints for consideration: [2] [3] I have set up a doodle to poll for a recurring meeting time for this subgroup: http://doodle.com/7wypkzqe9wep3d33#table (Timezone support is enabled) Currently the plan is to try G+ hangouts to run this meetings and scribe on #solum. This will limit us to a max of 10 participants. If we have more interest, we will need to see how to change the meetings. Thanks Krishna [1] https://blueprints.launchpad.net/solum/+spec/git-integration [2] https://blueprints.launchpad.net/solum/+spec/solum-git-push [3] https://blueprints.launchpad.net/solum/+spec/solum-git-pull___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Proposal to add Matt Riedemann to nova-core
+1 On Sat, Nov 23, 2013 at 7:23 AM, Russell Bryant rbry...@redhat.com wrote: Greetings, I would like to propose adding Matt Riedemann to the nova-core review team. Matt has been involved with nova for a long time, taking on a wide range of tasks. He writes good code. He's very engaged with the development community. Most importantly, he provides good code reviews and has earned the trust of other members of the review team. https://review.openstack.org/#/dashboard/6873 https://review.openstack.org/#/q/owner:6873,n,z https://review.openstack.org/#/q/reviewer:6873,n,z Please respond with +1/-1, or any further comments. Thanks, -- 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
Re: [openstack-dev] [Nova] Proposal to add Matt Riedemann to nova-core
+1 On Fri, Nov 22, 2013 at 2:41 PM, Christopher Yeoh cbky...@gmail.com wrote: +1 On Sat, Nov 23, 2013 at 7:23 AM, Russell Bryant rbry...@redhat.comwrote: Greetings, I would like to propose adding Matt Riedemann to the nova-core review team. Matt has been involved with nova for a long time, taking on a wide range of tasks. He writes good code. He's very engaged with the development community. Most importantly, he provides good code reviews and has earned the trust of other members of the review team. https://review.openstack.org/#/dashboard/6873 https://review.openstack.org/#/q/owner:6873,n,z https://review.openstack.org/#/q/reviewer:6873,n,z Please respond with +1/-1, or any further comments. Thanks, -- 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova
On Sat, Nov 23, 2013 at 8:33 AM, Matt Riedemann mrie...@linux.vnet.ibm.comwrote: ... 21:51:42 dolphm i just hope that the version discovery mechanism is smart enough to realize when it's handed a versioned endpoint, and happily run with that ... 21:52:00 dolphm (by calling that endpoint and doing proper discovery) ... 21:52:24 russellb dolphm: yeah, need to handle that gracefully ... Just one point here (and perhaps I'm misunderstanding what was meant), but if the catalog points to a versioned endpoint shouldn't we just use that version rather than trying to discover what other versions may be available. Although we'll have cases of it just being set to a versioned endpoint because thats how it has been done in the past I think we should be making the assumption that if we're pointed to a specific version, that is the one we should be using. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Working group on language packs
The breakout meeting schedule poll is published here (dates will be published here once they are selected): https://wiki.openstack.org/wiki/Solum/BreakoutMeetings#Language_Pack_Working_Group_Series If you would like to join the working group, please: 1) Subscribe to the lang-pack blueprint: https://blueprints.launchpad.net/solum/+spec/lang-pack 2) Participate in the doodle poll currently published on the wiki page referenced above to help select the best time for the meetings. Thanks, Adrian For those interested in joining this working group, On Nov 22, 2013, at 8:34 AM, Clayton Coleman ccole...@redhat.com wrote: I have updated the language pack (name subject to change) blueprint with the outcomes from the face2face meetings, and drafted a specification that captures the discussion so far. The spec is centered around the core idea of transitioning base images into deployable images (that can be stored in Nova and sent to Glance). These are *DRAFT* and are intended for public debate. https://blueprints.launchpad.net/solum/+spec/lang-pack https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/BuildingSourceIntoDeploymentArtifacts Please take this opportunity to review these documents and offer criticism and critique via the ML - I will schedule a follow up deep dive for those who expressed interest in participation [1] after US Thanksgiving. [1] https://etherpad.openstack.org/p/SolumWorkshopTrack1Notes ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to stage client major releases in Gerrit?
On Fri, Nov 22, 2013 at 1:13 PM, Robert Collins robe...@robertcollins.netwrote: On 22 November 2013 22:31, Thierry Carrez thie...@openstack.org wrote: Robert Collins wrote: I don't understand why branches would be needed here *if* the breaking changes don't impact any supported release of OpenStack. Right -- the trick is what does supported mean in that case. When the client libraries were first established as separate deliverables, they came up with a blanket statement that the latest version could always be used with *any* version of openstack you may have. The idea being, if some public cloud was still stuck in pre-diablo times, you could still use the same library to address both this public cloud and the one which was 2 weeks behind Havana HEAD. Huh. There are two different directions we use the client in. Client install - cloud API (of arbitrary version A) Server install (of arbitrary version B) using the Python library - cloud API (version B) From a gating perspective I think we want to check that: - we can use the client against some set of cloud versions A - that some set of version B where servers running cloud version B can use the client against cloud version B But today we don't test against ancient versions of A or B. If we were to add tests for such scenarios, I'd strongly argue that we only add then for case A. Where we are using the client lib in an installed cloud, we don't need to test that it can still be used against pre-diablo etc: such installed clouds can keep using the old client lib. I'm afraid that if a critical bug is found in the old client lib, the current path for fixing it is to ask people to update to the latest client version, even internally to their old cloud. So would that cause a branch for backporting fixes? FWIW, I don't think the changes glanceclient needs in v1 will break the 'B' case above. But it does raise a question--if they did, would it be sufficient to backport a change to adapt old supported stable B versions of, say, Nova, to work with the v1 client? Honestly asking, a big ol' NO is okay. So assuming you agree with that assertion, where do we need a branch here? -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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to stage client major releases in Gerrit?
On Fri, Nov 22, 2013 at 12:03 PM, Jeremy Stanley fu...@yuggoth.org wrote: On 2013-11-22 10:34:40 +0100 (+0100), Thierry Carrez wrote: It can be created on request by release management members (or infra-core team). I /think/ that by default it would get tested against master in other branches. More details at... URL: https://wiki.openstack.org/wiki/GerritJenkinsGithub#Merge_Commits Cool. Is this documentation essentially explaining how to keep a feature branch up to date with master? (spoiler warning: carefully use merge commits?) -- Jeremy Stanley ___ 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] Proposal to add Matt Riedemann to nova-core
+1 Solid reviewer! Sent from my iPad On Nov 22, 2013, at 2:53 PM, Russell Bryant rbry...@redhat.com wrote: Greetings, I would like to propose adding Matt Riedemann to the nova-core review team. Matt has been involved with nova for a long time, taking on a wide range of tasks. He writes good code. He's very engaged with the development community. Most importantly, he provides good code reviews and has earned the trust of other members of the review team. https://review.openstack.org/#/dashboard/6873 https://review.openstack.org/#/q/owner:6873,n,z https://review.openstack.org/#/q/reviewer:6873,n,z Please respond with +1/-1, or any further comments. Thanks, -- 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
Re: [openstack-dev] How to stage client major releases in Gerrit?
On 11/22/2013 06:55 PM, Mark Washenberger wrote: On Fri, Nov 22, 2013 at 1:13 PM, Robert Collins robe...@robertcollins.net mailto:robe...@robertcollins.net wrote: On 22 November 2013 22:31, Thierry Carrez thie...@openstack.org mailto:thie...@openstack.org wrote: Robert Collins wrote: I don't understand why branches would be needed here *if* the breaking changes don't impact any supported release of OpenStack. Right -- the trick is what does supported mean in that case. When the client libraries were first established as separate deliverables, they came up with a blanket statement that the latest version could always be used with *any* version of openstack you may have. The idea being, if some public cloud was still stuck in pre-diablo times, you could still use the same library to address both this public cloud and the one which was 2 weeks behind Havana HEAD. Huh. There are two different directions we use the client in. Client install - cloud API (of arbitrary version A) Server install (of arbitrary version B) using the Python library - cloud API (version B) From a gating perspective I think we want to check that: - we can use the client against some set of cloud versions A - that some set of version B where servers running cloud version B can use the client against cloud version B But today we don't test against ancient versions of A or B. If we were to add tests for such scenarios, I'd strongly argue that we only add then for case A. Where we are using the client lib in an installed cloud, we don't need to test that it can still be used against pre-diablo etc: such installed clouds can keep using the old client lib. I'm afraid that if a critical bug is found in the old client lib, the current path for fixing it is to ask people to update to the latest client version, even internally to their old cloud. So would that cause a branch for backporting fixes? The plan is that the current client libs should always be installable. So we would not (and never have) make a branch for backporting fixes. FWIW, I don't think the changes glanceclient needs in v1 will break the 'B' case above. But it does raise a question--if they did, would it be sufficient to backport a change to adapt old supported stable B versions of, say, Nova, to work with the v1 client? Honestly asking, a big ol' NO is okay. I'm not sure I follow all the pronouns. Could you re-state this again, I think I know what you're asking, but I'd like to be sure. So assuming you agree with that assertion, where do we need a branch here? -Rob -- Robert Collins rbtcoll...@hp.com mailto:rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ 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 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] [Solum] git-Integration working group
From: Monty Taylor mord...@inaugust.com Sent: Friday, November 22, 2013 6:24 PM To: openstack-dev@lists.openstack.org; Adrian Otto Subject: Re: [openstack-dev] [Solum] git-Integration working group On 11/22/2013 05:37 PM, Krishna Raman wrote: Hello all, I would like to kickoff the Git integration discussion. Goal of this subgroup is to go through the git-integration blueprint [1] and break it up into smaller blueprints that we can execute on. We have to consider 2 workflows: 1) For Milestone 1, pull based git workflow where user uses a public git repository (possibly on github) to trigger the build 2) For later milestones, a push based workflow where the git repository is maintained by Solum Hi! I'm a little disappointed that we've decided to base the initial workflow on something that is not related to the world-class git-based developer tooling that the OpenStack project has already produced. We have a GIANT amount of tooling in this space, and it's all quite scalable. RR: Can you provide some pointers to the tooling / Workflow you suggesting? Thanks There is also the intent by 3 or 4 different groups to make it more re-usable/re-consumable, including thoughts in making sure that we can drive it from and have it consume heat. Devdatta has created 2 blueprints for consideration: [2] [3] I have set up a doodle to poll for a /recurring/ meeting time for this subgroup: http://doodle.com/7wypkzqe9wep3d33#table (Timezone support is enabled) Currently the plan is to try G+ hangouts to run this meetings and scribe on #solum. This will limit us to a max of 10 participants. If we have more interest, we will need to see how to change the meetings. We have IRC meeting channels for meetings. They are logged - and they have the benefit that they do not require non-Open Source software to access. If you have them in IRC, the team from OpenStack who is already working on developer workflow around git can potentially participate. I don't mean to be negative, but if you want to be a PaaS for OpenStack, I would strongly consider not using G+ when we have IRC, and I would strongly suggest engaging with the Infra projects that already know how to do git-based workflow and action triggering. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to stage client major releases in Gerrit?
On 11/22/2013 09:57 AM, Dolph Mathews wrote: On Fri, Nov 22, 2013 at 3:31 AM, Thierry Carrez thie...@openstack.org mailto:thie...@openstack.org wrote: Robert Collins wrote: I don't understand why branches would be needed here *if* the breaking changes don't impact any supported release of OpenStack. Right -- the trick is what does supported mean in that case. When the client libraries were first established as separate deliverables, they came up with a blanket statement that the latest version could always be used with *any* version of openstack you may have. The idea being, if some public cloud was still stuck in pre-diablo times, you could still use the same library to address both this public cloud and the one which was 2 weeks behind Havana HEAD. I'm curious about the historical circumstance of this requirement -- were the services supported master, minus two releases at the time? We're not testing more than two stable releases against the latest clients in CI today, so I find it odd that we still bother with this claim, without demonstrating that it's true. The design of this comes from an end-user perspective. If Alice wants to use a cloud, Bob, Alice should download the current python-glanceclient library, provide it with her credentials, and it should work, regardless of what version of OpenStack Bob's operator happens to be running. The reason for the above is that any other approach is a TERRIBLE end user experience. (As a person who currently is involved with running a scalable cloud application on two OpenStack clouds that are wildly different versions, I can tell you, needing to install different client library versions to talk to them would be madness. That's about outbound API versions though. That means that master *client must always be able to speak to every extant API version. This question is actually about python API consumption, and when we made the policy, we did discuss that were a breaking change to be made in the Python API, clearly the semver Major version should be bumped. Unfortunately for this conversation, we stopped with Brian Waldon's assertion of the major version bump and did not design a system to handle it. We do not currently have the machinery to handle it. At the very latest, we would need to design a modification to how zuul and devstack-gate construct collections of changesets. That said - we need to think about the questions raised above in terms of support of python API. But, more importantly, we should really think long and hard about breaking the python API, even with a major version bump, because no matter how you do it, it's disruptive to library consumers. -- Thierry Carrez (ttx) ___ 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 -- -Dolph ___ 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] [Solum] git-Integration working group
Monty, On Nov 22, 2013, at 6:24 PM, Monty Taylor mord...@inaugust.com wrote: On 11/22/2013 05:37 PM, Krishna Raman wrote: Hello all, I would like to kickoff the Git integration discussion. Goal of this subgroup is to go through the git-integration blueprint [1] and break it up into smaller blueprints that we can execute on. We have to consider 2 workflows: 1) For Milestone 1, pull based git workflow where user uses a public git repository (possibly on github) to trigger the build 2) For later milestones, a push based workflow where the git repository is maintained by Solum Hi! Hi, thanks for chiming in here. I'm a little disappointed that we've decided to base the initial workflow on something that is not related to the world-class git-based developer tooling that the OpenStack project has already produced. We have a GIANT amount of tooling in this space, and it's all quite scalable. There is also the intent by 3 or 4 different groups to make it more re-usable/re-consumable, including thoughts in making sure that we can drive it from and have it consume heat. The initial work will be something pretty trivial. It's just a web hook on a git push. The workflow in this case is not customizable, and has basically no features. The intent is to iterate on this to make it much more compelling over time, soon after the minimum integration, we will put a real workflow system in place. We did discuss Zuul and Nodepool, and nobody had any objection to learning more about those. This might be a bit early in our roadmap to be pulling them in, but if there is an easy way to use them early in our development, we'd like to explore that. Devdatta has created 2 blueprints for consideration: [2] [3] I have set up a doodle to poll for a /recurring/ meeting time for this subgroup: http://doodle.com/7wypkzqe9wep3d33#table (Timezone support is enabled) Currently the plan is to try G+ hangouts to run this meetings and scribe on #solum. This will limit us to a max of 10 participants. If we have more interest, we will need to see how to change the meetings. We have IRC meeting channels for meetings. They are logged - and they have the benefit that they do not require non-Open Source software to access. If you have them in IRC, the team from OpenStack who is already working on developer workflow around git can potentially participate. I don't mean to be negative, but if you want to be a PaaS for OpenStack, I would strongly consider not using G+ when we have IRC, and I would strongly suggest engaging with the Infra projects that already know how to do git-based workflow and action triggering. We just finished holding the Solum Community Design Workshop in San Francisco. We had both irc and G+ in addition to etherpad for shared notetaking. What we found is that that collaboration was faster and more effective when we used the G+ tool. The remote participants had a strong preference for it, and requested that we use it for the breakout meetings as well. The breakout design meetings will have a scribe who will transcribe the interaction in IRC so it will also be logged. Please recognize that we have not yet considered an alternate point of view on either of these subjects yet, because one has not been raised until now. I'm open to suggestions for how best to engage the experts on git integration so we can benefit from the expertise in our community. Thanks, Adrian ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Solum] Working group on language packs
On 11/22/2013 11:34 AM, Clayton Coleman wrote: I have updated the language pack (name subject to change) blueprint with the outcomes from the face2face meetings, and drafted a specification that captures the discussion so far. The spec is centered around the core idea of transitioning base images into deployable images (that can be stored in Nova and sent to Glance). These are *DRAFT* and are intended for public debate. https://blueprints.launchpad.net/solum/+spec/lang-pack https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/BuildingSourceIntoDeploymentArtifacts Please take this opportunity to review these documents and offer criticism and critique via the ML - I will schedule a follow up deep dive for those who expressed interest in participation [1] after US Thanksgiving. Hi! I'd strongly suggest looking at the diskimage-builder project that's part of the TripleO program. Someone has already done a POC of turning it in to an aaS, and there are already people working on tying diskimage-builder elements and heat templates. Given that OpenStack has prior art and work in this direction, you should be able to accelerate getting to your goals pretty quickly. [1] https://etherpad.openstack.org/p/SolumWorkshopTrack1Notes ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder][Glance] OSLO update
On 11/20/2013 07:04 AM, Roman Bogorodskiy wrote: I know it was brought up on the list a number of times, but... If we're talking about storing commit ids for each module and writing some shell scripts for that, isn't it a chance to reconsider using git submodules? No. They're too complex. We don't allow merge commits because they're too easy to mess up. Even seasoned (and I mean SEASONED git devs) shy away from submodules because the semantics are tricky. We have 1600 devs - advanced git features lead us to death. (I say this as the person who fields questions about basic git features) On Wed, Nov 20, 2013 at 12:37 PM, Elena Ezhova eezh...@mirantis.com mailto:eezh...@mirantis.com wrote: 20.11.2013, 06:18, John Griffith john.griff...@solidfire.com mailto:john.griff...@solidfire.com: On Mon, Nov 18, 2013 at 3:53 PM, Mark McLoughlin mar...@redhat.com mailto:mar...@redhat.com wrote: On Mon, 2013-11-18 at 17:24 +, Duncan Thomas wrote: Random OSLO updates with no list of what changed, what got fixed etc are unlikely to get review attention - doing such a review is extremely difficult. I was -2ing them and asking for more info, but they keep popping up. I'm really not sure what the best way of updating from OSLO is, but this isn't it. Best practice is to include a list of changes being synced, for example: https://review.openstack.org/54660 Every so often, we throw around ideas for automating the generation of this changes list - e.g. cinder would have the oslo-incubator commit ID for each module stored in a file in git to tell us when it was last synced. Mark. _ __ 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 Been away on vacation so I'm afraid I'm a bit late on this... but; I think the point Duncan is bringing up here is that there are some VERY large and significant patches coming from OSLO pulls. The DB patch in particular being over 1K lines of code to a critical portion of the code is a bit unnerving to try and do a review on. I realize that there's a level of trust that goes with the work that's done in OSLO and synchronizing those changes across the projects, but I think a few key concerns here are: 1. Doing huge pulls from OSLO like the DB patch here are nearly impossible to thoroughly review and test. Over time we learn a lot about real usage scenarios and the database and tweak things as we go, so seeing a patch set like this show up is always a bit unnerving and frankly nobody is overly excited to review it. 2. Given a certain level of *trust* for the work that folks do on the OSLO side in submitting these patches and new additions, I think some of the responsibility on the review of the code falls on the OSLO team. That being said there is still the issue of how these changes will impact projects *other* than Nova which I think is sometimes neglected. There have been a number of OSLO synchs pushed to Cinder that fail gating jobs, some get fixed, some get abandoned, but in either case it shows that there wasn't any testing done with projects other than Nova (PLEASE note, I'm not referring to this particular round of patches or calling any patch set out, just stating a historical fact). 3. We need better documentation in commit messages explaining why the changes are necessary and what they do for us. I'm sorry but in my opinion the answer it's the latest in OSLO and Nova already has it is not enough of an answer in my opinion. The patches mentioned in this thread in my opinion met the minimum requirements because they at least reference the OSLO commit which is great. In addition I'd like to see something to address any discovered issues or testing done with the specific projects these changes are being synced to. I'm in no way saying I don't want Cinder to play nice with the common code or to get in line with the way other projects do things but I am saying that I think we have a ways to go in terms of better communication here and in terms of OSLO code actually keeping in mind the entire OpenStack eco-system as opposed to just changes that were needed/updated in Nova. Cinder in particular went through some
Re: [openstack-dev] RFC: Potential to increase min required libvirt version to 0.9.11 ?
On 11/22/2013 01:02 PM, Daniel P. Berrange wrote: On Wed, Nov 20, 2013 at 04:02:02PM +0100, Ralf Haferkamp wrote: On Wed, Nov 20, 2013 at 04:33:22PM +1300, Robert Collins wrote: On 20 November 2013 08:02, Daniel P. Berrange berra...@redhat.com wrote: Currently the Nova libvirt driver is declaring that it wants a minimum of libvirt 0.9.6. ... If there are other distros I've missed which expect to support deployment of Icehouse please add them to this list. Hopefully there won't be any with libvirt software older than Ubuntu 12.04 LTS The reason I'm asking this now, is that we're working to make the libvirt python module a separate tar.gz that can build with multiple libvirt versions, and I need to decide how ancient a libvirt we should support for it. Fantastic!!! The Ubuntu cloud archive https://wiki.ubuntu.com/ServerTeam/CloudArchive is how OpenStack is delivered by Canonical for Ubuntu LTS users. So I think you can go with e.g. 0.9.11 or even 0.9.12 depending on what the Suse folk say. I think 0.9.11 is fine for us. I am not worried too much about 0.9.12 either since openSUSE 12.2 (which has 0.9.11) will reach its EOL soon. I also added SLES to the table on: https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix Thanks, it looks like from the libvirt side, we are only going to be able to provide a standalone libvirt-python on PyPI that works back to version 0.9.11. Prior to 0.9.11 libvirt did not install its API description, which is a pre-requisite for the python bindings to build. Fortunately 0.9.11 lines up with all the distros we've got listed so far. I, for one, welcome our new libvirt overlords. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] RFC: Potential to increase min required libvirt version to 0.9.11 ?
Hi, On Fri, Nov 22, 2013 at 3:29 PM, Jeremy Stanley fu...@yuggoth.org wrote: On 2013-11-20 03:50:03 + (+), Tom Fifield wrote: Just confirming that the documentation for Ubuntu sets users up with the Cloud Archive. In Havana, Libvirt is 1.1.1 and qemu is 1.5.0. I've added a row to the table. There's a change currently up for review to (yet once more) try using Ubuntu Cloud Archive for the testing we perform on Ubuntu Precise (which is most of the testing we do as a project at the moment). https://review.openstack.org/48226 Unfortunately, the last time we tried we ran into a buggy version of libvirt there. https://launchpad.net/bugs/1228977 At the moment, we're still looking for confirmation that nova-compute no longer locks up with the latest libvirt in UCA (1.1.1). I'm going to run some manual tests, but anyone who can pitch in and confirm this bug is completely flushed out now would be most appreciated. I certainly don't want to introduce yet another nondeterministic bug into our integrated gate tests, especially after everything else we've been through in that regard this week. -- This should be fixed in the cloud archive, please let me know if you still have problems. Jeremy Stanley ___ 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] [Solum] Working group on language packs
On Nov 22, 2013, at 9:54 PM, Monty Taylor mord...@inaugust.com wrote: On 11/22/2013 11:34 AM, Clayton Coleman wrote: I have updated the language pack (name subject to change) blueprint with the outcomes from the face2face meetings, and drafted a specification that captures the discussion so far. The spec is centered around the core idea of transitioning base images into deployable images (that can be stored in Nova and sent to Glance). These are *DRAFT* and are intended for public debate. https://blueprints.launchpad.net/solum/+spec/lang-pack https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/BuildingSourceIntoDeploymentArtifacts Please take this opportunity to review these documents and offer criticism and critique via the ML - I will schedule a follow up deep dive for those who expressed interest in participation [1] after US Thanksgiving. Hi! I'd strongly suggest looking at the diskimage-builder project that's part of the TripleO program. Someone has already done a POC of turning it in to an aaS, and there are already people working on tying diskimage-builder elements and heat templates. Given that OpenStack has prior art and work in this direction, you should be able to accelerate getting to your goals pretty quickly. diskimage-builder is definitely a primary tool choice for an openstack deployer creating vm images, and should certainly be promoted where possible. I'll add an example to the doc. The spec does try to be agnostic to the actual image creation technology in play - organizations using containers or Windows images may have alternative preferences about the underlying mechanism by which they generate images. Decoupling the image creation from how the image is used is a key goal, especially since organizations often want to separate environment preparation and development along role lines. [1] https://etherpad.openstack.org/p/SolumWorkshopTrack1Notes ___ 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] [Solum] Working group on language packs
Excerpts from Clayton Coleman's message of 2013-11-22 21:43:40 -0800: On Nov 22, 2013, at 9:54 PM, Monty Taylor mord...@inaugust.com wrote: On 11/22/2013 11:34 AM, Clayton Coleman wrote: I have updated the language pack (name subject to change) blueprint with the outcomes from the face2face meetings, and drafted a specification that captures the discussion so far. The spec is centered around the core idea of transitioning base images into deployable images (that can be stored in Nova and sent to Glance). These are *DRAFT* and are intended for public debate. https://blueprints.launchpad.net/solum/+spec/lang-pack https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/BuildingSourceIntoDeploymentArtifacts Please take this opportunity to review these documents and offer criticism and critique via the ML - I will schedule a follow up deep dive for those who expressed interest in participation [1] after US Thanksgiving. Hi! I'd strongly suggest looking at the diskimage-builder project that's part of the TripleO program. Someone has already done a POC of turning it in to an aaS, and there are already people working on tying diskimage-builder elements and heat templates. Given that OpenStack has prior art and work in this direction, you should be able to accelerate getting to your goals pretty quickly. diskimage-builder is definitely a primary tool choice for an openstack deployer creating vm images, and should certainly be promoted where possible. I'll add an example to the doc. The spec does try to be agnostic to the actual image creation technology in play - organizations using containers or Windows images may have alternative preferences about the underlying mechanism by which they generate images. Decoupling the image creation from how the image is used is a key goal, especially since organizations often want to separate environment preparation and development along role lines. Windows images are special, yes. For those, perhaps chat with the Murano folk? Containers will work fine in diskimage-builder. One only needs to hack in the ability to save in the container image format rather than qcow2. I actually think diskimage-builder would be really useful for container building, as it doesn't make any assumptions about things like having a kernel. In fact we've discussed the possibility of using lxc to do the image builds instead of chroot so that the builds would be more isolated from the build host. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
