Re: [openstack-dev] [Fuel] Plugins for Fuel: repo, doc, spec - where?
What sort of specification are you talking about here -- specs for individual plugins or a spec for how to implement a plugin? If the latter, what is the relationship of that to the official documentation about how to create a plugin (to be added to the Developer Guide)? meg On Fri, Jan 23, 2015 at 1:43 AM, Nikolay Markov wrote: > I also wanted to add that there is a PR already on adding plugins > repos to stackforge: https://review.openstack.org/#/c/147169/ > > There is a battle in comments right now, because some people are not > agree that so many repos are needed. > > On Fri, Jan 23, 2015 at 1:25 AM, Mike Scherbakov > wrote: > > Hi Fuelers, > > we've implemented pluggable architecture piece in 6.0, and got a number > of > > plugins already. Overall development process for plugins is still not > fully > > defined. > > We initially thought that having all the plugins in one repo on > stackforge > > is Ok, we also put some docs into existing fuel-docs repo, and specs to > > fuel-specs. > > > > We might need a change here. Plugins are not tight to any particular > release > > date, and they can also be separated each from other in terms of > committers > > and core reviewers. Also, it seems to be pretty natural to keep all docs > and > > design specs associated with particular plugin. > > > > With all said, following best dev practices, it is suggested to: > > > > Have a separate stackforge repo per Fuel plugin in format > > "fuel-plugin-", with separate core-reviewers group which should > have > > plugin contributor initially > > Have docs folder in the plugin, and ability to build docs out of it > > > > do we want Sphinx or simple Github docs format is Ok? So people can just > go > > to github/stackforge to see docs > > > > Have specification in the plugin repo > > > > also, do we need Sphinx here? > > > > Have plugins tests in the repo > > > > Ideas / suggestions / comments? > > Thanks, > > -- > > Mike Scherbakov > > #mihgen > > > > > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > -- > Best regards, > Nick Markov > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [fuel]
Hi, Tomasz, Gee, that sentence seemed just fine until I saw how foss geek interpreted it ;-) So I reworded that sentence, then I added a second sentence to try to capture what you wrote. I'm not sure about that second sentence -- what do you think? I don't want to write a manual about how to deploy without Fuel but a little hint can be nice... https://review.openstack.org/#/c/134070/1 Thanks much, meg On Wed, Nov 12, 2014 at 9:07 AM, Tomasz Napierala wrote: > > On 12 Nov 2014, at 17:56, foss geek wrote: > > > > > I am reading Fuel reference-architecture documentation in the below link: > > > > > http://docs.mirantis.com/openstack/fuel/fuel-5.1/reference-architecture.html#openstack-environment-architecture > > > > In the page no 2 note says: > > > > Note > > > > In environments that use vCenter as the hypervisor, the Nova-compute > service can run only on Controller nodes. > > > > Is it specific to Fuel? > > > > Let say I deployed a environment (controller + compute + storage) with > KVM as the hypervisor and later manually doing all the necessary > configuration change to make compute node with vCenter as the hypervisor. > In this case does Nova-compute (running in compute-node) service work with > vCenter? > > > > This is Fuel specific. We’ve just decided to put nova-compute responsible > to control vCenter on controller nodes. You can configure it on any node > you want, similar to any other service. You just need to take care of > access to vCenter control plane. > > Regards, > -- > Tomasz 'Zen' Napierala > Sr. OpenStack Engineer > tnapier...@mirantis.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] [Fuel] Fuel standards
Could we specify that all Fuel configuration files should include all allowable parameters. The optional parameters can be commented out but being able to uncomment and populate a parameter is a lot easier than having to find the exact name and order. For bonus points, we could include commentary about when and how to activate these optional parameters but we could also cover this in the documentation for each configuration file. meg On Tue, Oct 28, 2014 at 1:08 AM, Dmitriy Shulyak wrote: > > >> Let's do the same for Fuel. Frankly, I'd say we could take OpenStack >> standards as is and use them for Fuel. But maybe there are other opinions. >> Let's discuss this and decide what to do. Do we actually need those >> standards at all? >> >> Agree that we can take openstack standarts as example, but lets not > simply copy them and just live with it. > >> >> 0) Standard for projects naming. >> Currently most of Fuel projects are named like fuel-whatever or even >> whatever? Is it ok? Or maybe we need some formal rules for naming. For >> example, all OpenStack clients are named python-someclient. Do we need to >> rename fuelclient into python-fuelclient? >> > I dont like that fuel is added into every project that we start, correct > me if I am wrong but: > - shotgun can be self-contained project, and still provide certain value, > actually i think it can be used by jenkins in our and openstack gates > to copy logs and other info > - same for network verification tool > - fuel_agent (image based provisioning) can work without all other fuel > parts > >> >> 1) Standard for an architecture. >> Most of OpenStack services are split into several independent parts >> (raughly service-api, serivce-engine, python-serivceclient) and those parts >> interact with each other via REST and AMQP. python-serivceclient is usually >> located in a separate repository. Do we actually need to do the same for >> Fuel? According to fuelclient it means it should be moved into a separate >> repository. Fortunately, it already uses REST API for interacting with >> nailgun. But it should be possible to use it not only as a CLI tool, but >> also as a library. >> >> 2) Standard for project directory structure (directory names for api, db >> models, drivers, cli related code, plugins, common code, etc.) >> Do we actually need to standardize a directory structure? >> >> Well, we need some project, agree on that project structure and then just > provide as example during review. > We can choose: > - fuelclient as cli example (but first refactor it) > - fuel-stats as web app example > >> 3) Standard for third party libraries >> As far as Fuel is a deployment tool for OpenStack, let's make a decision >> about using OpenStack components wherever it is possible. >> 3.1) oslo.config for configuring. >> 3.2) oslo.db for database layer >> 3.3) oslo.messaging for AMQP layer >> 3.4) cliff for CLI (should we refactor fuelclient so as to make based on >> cliff?) >> 3.5) oslo.log for logging >> 3.6) stevedore for plugins >> etc. >> What about third party components which are not OpenStack related? What >> could be the requirements for an arbitrary PyPi package? >> > In my opinion we should not pick some library just because it is used in > openstack, there should be some research and analys, > for example: > Cli application, there is several popular alternatives to cliff in python > community: > - https://github.com/docopt/docopt > - https://github.com/mitsuhiko/click > I personnaly would prefer to use docopt, but click looks good as well. > Web frameworks is whole different story, in python community we have > mature flask and pyramid, > and i dont see any benefits from using pecan. > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] How can we get more feedback from users?
Terrific idea! So what happens with the feedback you receive? I am, of course, most interested in issues that might help us improve the documentation, of course, but it's a general question about how this information flows to the Product Engineering team. meg On Thu, Oct 23, 2014 at 11:46 PM, Tim Bell wrote: > Angus, > > > > There are two groups which may be relevant regarding ‘consumers’ of Heat > > > > -Application eco system working group at > https://wiki.openstack.org/wiki/Application_Ecosystem_Working_Group > > -API working group at > https://wiki.openstack.org/wiki/API_Working_Group > > > > There are some discussions planned as part of the breakouts in the Kilo > design summit (http://kilodesignsummit.sched.org/) > > > > So, there are frameworks in place and we would welcome volunteers to help > advance these in a consistent way across the OpenStack programs. > > > > Tim > > > > *From:* Angus Salkeld [mailto:asalk...@mirantis.com] > *Sent:* 24 October 2014 08:16 > *To:* Stefano Maffulli > *Cc:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [all] How can we get more feedback from > users? > > > > On Fri, Oct 24, 2014 at 4:00 PM, Stefano Maffulli > wrote: > > Hi Angus, > > quite a noble intent, one that requires lots of attempts like this you > have started. > > On 10/23/2014 09:32 PM, Angus Salkeld wrote: > > I have felt some grumblings about usability issues with Heat > > templates/client/etc.. > > and wanted a way that users could come and give us feedback easily (low > > barrier). I started an etherpad > > (https://etherpad.openstack.org/p/heat-useablity-improvements) - the > > first win is it is spelt wrong :-O > > :) > > > We now have some great feedback there in a very short time, most of this > > we should be able to solve. > > > > This lead me to think, "should OpenStack have a more general mechanism > > for users to provide feedback". The idea is this is not for bugs or > > support, but for users to express pain points, requests for features and > > docs/howtos. > > One place to start is to pay attention to what happens on the operators > mailing list. Posting this message there would probably help since lots > of users hang out there. > > In Paris there will be another operators mini-summit, the fourth IIRC, > one every 3 months more or less (I can't find the details at the moment, > I assume they'll be published soon -- Ideas are being collected on > https://etherpad.openstack.org/p/PAR-ops-meetup). > > > > Thanks for those pointers, we very interested in feedback from operators, > but > > in this case I am talking more about end users not operators (people that > actually use our API). > > -Angus > > > > Another effort to close this 'feedback loop' is the new working group > temporarily named 'influencers' that will meet in Paris for the first > time: > > https://openstacksummitnovember2014paris.sched.org/event/268a9853812c22ca8d0636b9d8f0c831 > > It's great to see lots of efforts going in the same direction. Keep 'em > coming. > > /stef > > -- > Ask and answer questions on https://ask.openstack.org > > > > ___ > 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
