Re: [openstack-dev] [Heat] Defining what is a SupportStatus version
Le 2014-09-08 17:10, Anne Gentle a écrit : On Fri, Sep 5, 2014 at 5:27 AM, Steven Hardy sha...@redhat.com wrote: On Fri, Sep 05, 2014 at 03:56:34PM +1000, Angus Salkeld wrote: On Fri, Sep 5, 2014 at 3:29 PM, Gauvain Pocentek gauvain.pocen...@objectif-libre.com wrote: Hi, A bit of background: I'm working on the publication of the HOT resources reference on docs.openstack.org [1]. This book is mostly autogenerated from the heat source code, using the sphinx XML output. To avoid publishing several references (one per released version, as is done for the OpenStack config-reference), I'd like to add information about the support status of each resource (when they appeared, when they've been deprecated, and so on). So the plan is to use the SupportStatus class and its `version` attribute (see https://review.openstack.org/#/c/116443/ [2] ). And the question is, what information should the version attribute hold? Possibilities include the release code name (Icehouse, Juno), or the release version (2014.1, 2014.2). But this wouldn't be useful for users of clouds continuously deployed. From my documenter point of view, using the code name seems the right option, because it fits with the rest of the documentation. What do you think would be the best choice from the heat devs POV? IMHO it should match the releases and tags (https://github.com/openstack/heat/releases [3]). +1 this makes sense to me. Couldn't we have the best of both worlds by having some logic in the docs generation code which maps the milestone to the release series, so we can say e.g Supported since 2014.2.b3 (Juno) I agree with the matching of releases, but let's set expectations for how often it'll be generated. That is to say, each tag is a bit much to ask. I think that even each milestone is asking a bit much. How about each release and include the final rc tag (2014.2?) This option looks good to me. Gauvain This would provide sufficient detail to be useful to both folks consuming the stable releases and those trunk-chasing via CD? Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [4] Links: -- [1] http://docs.openstack.org [2] https://review.openstack.org/#/c/116443/ [3] https://github.com/openstack/heat/releases [4] 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] [Neutron][Architecture]Suggestions for the third vendors' plugin and driver
Hi, While keeping focused on defining proper approach to deal with Neutron third vendors’ plugin and driver, we also need to provide solution for complimentary critical piece of code maintained in the Nova code base. Introducing new vif_type by neutron L2 Plugin/Driver, requires adding vif plugging support at Nova side. I think it is very important to enable virt driver extensibility to support out of the tree/future vif_types. If the direction is to keep vendor plugins/drivers external to Neutron core, it seems reasonable to impose same policy on the Nova side. BR, Irena From: Kevin Benton [mailto:blak...@gmail.com] Sent: Friday, September 12, 2014 12:19 PM To: OpenStack Development Mailing List (not for usage questions) Cc: tanny...@huawei.com Subject: Re: [openstack-dev] [Neutron][Architecture]Suggestions for the third vendors' plugin and driver So my suggestion is remove all vendors' plugins and drivers except opensource as built-in. Yes, I think this is currently the view held by the PTL (Kyle) and some of the other cores so what you're suggesting will definitely come up at the summit. Why do we need a different repo to store vendors' codes? That's not the community business. I think only a proper architecture and normal NBSB API can bring a clear separation between plugins(or drivers) and core code, not a different repo. The problem is that that architecture won't stay stable if there is no shared community plugin depending on its stability. Let me ask you the inverse question. Why do you think the reference driver should stay in the core repo? A separate repo won't have an impact on what is packaged and released so it should have no impact on user experience, complete versions, providing code examples, or developing new features. In fact, it will likely help with the last two because it will provide a clear delineation between what a plugin is responsible for vs. what the core API is responsible for. And, because new cores can be added faster to the open source plugins repo due to a smaller code base to learn, it will help with developing new features by reducing reviewer load. On Fri, Sep 12, 2014 at 1:50 AM, Germy Lure germy.l...@gmail.commailto:germy.l...@gmail.com wrote: On Fri, Sep 12, 2014 at 11:11 AM, Kevin Benton blak...@gmail.commailto:blak...@gmail.com wrote: Maybe I missed something, but what's the solution? There isn't one yet. That's why it's going to be discussed at the summit. So my suggestion is remove all vendors' plugins and drivers except opensource as built-in. By leaving open source plugins and drivers in the tree , we can resolve such problems: 1)release a workable and COMPLETE version 2)user experience(especially for beginners) 3)provide code example to learn for new contributors and vendors 4)develop and verify new features I think we should release a workable version. Definitely. But that doesn't have anything to do with it living in the same repository. By putting it in a different repo, it provides smaller code bases to learn for new contributors wanting to become a core developer in addition to a clear separation between plugins and core code. Why do we need a different repo to store vendors' codes? That's not the community business. I think only a proper architecture and normal NBSB API can bring a clear separation between plugins(or drivers) and core code, not a different repo. Of course, if the community provides a wiki page for vendors to add hyperlink of their codes, I think it's perfect. Besides of user experience, the open source drivers are also used for developing and verifying new features, even small-scale case. Sure, but this also isn't affected by the code being in a separate repo. See comments above. The community should and just need focus on the Neutron core and provide framework for vendors' devices. I agree, but without the open source drivers being separated as well, it's very difficult for the framework for external drivers to be stable enough to be useful. Architecture and API. The community should ensure core and API stable enough and high quality. Vendors for external drivers. Who provides, who maintains(including development, storage, distribution, quality, etc). On Thu, Sep 11, 2014 at 7:24 PM, Germy Lure germy.l...@gmail.commailto:germy.l...@gmail.com wrote: Some comments inline. BR, Germy On Thu, Sep 11, 2014 at 5:47 PM, Kevin Benton blak...@gmail.commailto:blak...@gmail.com wrote: This has been brought up several times already and I believe is going to be discussed at the Kilo summit. Maybe I missed something, but what's the solution? I agree that reviewing third party patches eats community time. However, claiming that the community pays 46% of it's energy to maintain vendor-specific code doesn't make any sense. LOC in the repo has very little to do with ongoing required maintenance. Assuming the APIs for the plugins stay consistent, there should be few
Re: [openstack-dev] [Heat] Defining what is a SupportStatus version
Excerpts from Gauvain Pocentek's message of 2014-09-04 22:29:05 -0700: Hi, A bit of background: I'm working on the publication of the HOT resources reference on docs.openstack.org. This book is mostly autogenerated from the heat source code, using the sphinx XML output. To avoid publishing several references (one per released version, as is done for the OpenStack config-reference), I'd like to add information about the support status of each resource (when they appeared, when they've been deprecated, and so on). So the plan is to use the SupportStatus class and its `version` attribute (see https://review.openstack.org/#/c/116443/ ). And the question is, what information should the version attribute hold? Possibilities include the release code name (Icehouse, Juno), or the release version (2014.1, 2014.2). But this wouldn't be useful for users of clouds continuously deployed. From my documenter point of view, using the code name seems the right option, because it fits with the rest of the documentation. What do you think would be the best choice from the heat devs POV? What we ship in-tree is the standard library for Heat. I think Heat should not tie things to the release of OpenStack, but only to itself. The idea is to simply version the standard library of resources separately even from the language. Added resources and properties would be minor bumps, deprecating or removing anything would be a major bump. Users then just need an API call that allows querying the standard library version. With this scheme, we can provide a gate test that prevents breaking the rules, and automatically generate the docs still. Doing this would sync better with continuous deployers who will be running Juno well before there is a 2014.2. Anyway, Heat largely exists to support portability of apps between OpenStack clouds. Many many OpenStack clouds don't run one release, and we don't require them to do so. So tying to the release is, IMO, a poor coice. We do the same thing with HOT's internals, so why not also do the standard library this way? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Attach an USB disk to VM [nova]
Hi, Is there any way to attach an USB disk as an external disk to VM while booting up the VM ? Any help in this respect will be really helpful. Thanks fipuzzles ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Attach an USB disk to VM [nova]
What is your concrete user scenario for this request? Where do you expect to plugin the USB disk? On the compute node that hosts the VM or from somewhere else? On Mon, Sep 15, 2014 at 3:01 AM, pratik maru fipuzz...@gmail.com wrote: Hi, Is there any way to attach an USB disk as an external disk to VM while booting up the VM ? Any help in this respect will be really helpful. Thanks fipuzzles ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards, Xiandong Meng mengxiand...@gmail.com mengxiand...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] China blocking access to OpenStack git review push
As an alternative to pushing via ssh you can push via https over port 443 which may bypass this port blockage. Both latest git review and the version of gerrit that we are running support this. The first step is to generate a gerrit http password, this will be used to authenticate against Gerrit. Go to https://review.openstack.org/#/settings/http-password and generate a password there (note this is independent of your launchpad openid password). Next step is to get some code clone it from eg https://git.openstack.org/openstack-dev/sandbox. Now I am sure there is a better way to have git-review do this for you with config overrides somewhere but we need to add a git remote in that repo called 'gerrit'. By default all of our .gitreview files set this up for ssh so we will manually add one. `git remote add gerrit https://usern...@review.openstack.org/openstack-dev/sandbox`. Finally run `git review -s` to get the needed commit hook and now you are ready to push code with `git review` as you normally would. Note when git review asks for a password it will want the password we generated in the first step. I am pretty sure this is can be made easier and the manual git remote step is not required if you set up some overrides in git(review) config files. Maybe the folks that added https support for git review can fill us in. Clark Thanks, Clark. The HTTPS way worked for me. There is one additional inconvenience, though. Everytime I do 'git review', I have to input the password twice, and the password has to be input using a GNOME window instead from command line (SSH'ed). Are you aware of 1) a place to save this password so that I don't have to input it every time? 2) a configuration option that allow me to input password from remote console? I'm not considering a X11 forward at the moment. Thanks. Regards, - Qiming ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Attach an USB disk to VM [nova]
Hi Xian, Thanks for replying. I have some data which i wants to be passed to VM. To pass this data, I have planned this to attach as an usb disk and this disk will be used inside the vm to read the data. What I am looking is for the functionality similar to -usb option with qemu.kvm command. Please let me know, how it can be achieved in openstack environment. Thanks fipuzzles On Mon, Sep 15, 2014 at 8:14 AM, Xiandong Meng mengxiand...@gmail.com wrote: What is your concrete user scenario for this request? Where do you expect to plugin the USB disk? On the compute node that hosts the VM or from somewhere else? On Mon, Sep 15, 2014 at 3:01 AM, pratik maru fipuzz...@gmail.com wrote: Hi, Is there any way to attach an USB disk as an external disk to VM while booting up the VM ? Any help in this respect will be really helpful. Thanks fipuzzles ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards, Xiandong Meng mengxiand...@gmail.com mengxiand...@gmail.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] Attach an USB disk to VM [nova]
Try to use Nova Metadata Serivce [1] or Nova Config Drive [2]. There are options to pass Key-Value data as well as whole files during VM boot. [1] http://docs.openstack.org/grizzly/openstack-compute/admin/content/metadata-service.html [2] http://docs.openstack.org/grizzly/openstack-compute/admin/content/config-drive.html Best regards, Max Lobur, OpenStack Developer, Mirantis, Inc. Mobile: +38 (093) 665 14 28 Skype: max_lobur 38, Lenina ave. Kharkov, Ukraine www.mirantis.com www.mirantis.ru On Sun, Sep 14, 2014 at 10:21 PM, pratik maru fipuzz...@gmail.com wrote: Hi Xian, Thanks for replying. I have some data which i wants to be passed to VM. To pass this data, I have planned this to attach as an usb disk and this disk will be used inside the vm to read the data. What I am looking is for the functionality similar to -usb option with qemu.kvm command. Please let me know, how it can be achieved in openstack environment. Thanks fipuzzles On Mon, Sep 15, 2014 at 8:14 AM, Xiandong Meng mengxiand...@gmail.com wrote: What is your concrete user scenario for this request? Where do you expect to plugin the USB disk? On the compute node that hosts the VM or from somewhere else? On Mon, Sep 15, 2014 at 3:01 AM, pratik maru fipuzz...@gmail.com wrote: Hi, Is there any way to attach an USB disk as an external disk to VM while booting up the VM ? Any help in this respect will be really helpful. Thanks fipuzzles ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards, Xiandong Meng mengxiand...@gmail.com mengxiand...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
