Re: [Kimchi-devel] [Proposal] Introducing the version in REST API URI for kimchi/ginger plugins
by Aline Manera
On 06/08/2015 16:21, Harshal Patil wrote:
> Typical use case... I write a fancy bindings for wok RESTful APIs say,
> in Haskell (because yeah! ;-) ). For the given endpoint (let's say
> /abc) there is a JSON response you get for the GET method. Everything
> is working fine until wok developers figure out that with the changing
> needs may be the JSON sent as a response by /abc GET might need to
> change. At this point if our RESTful API supports versioning poor
> Haskell loving engineers can still be sure that their bindings will
> work properly while giving the flexibility to wok developers to change
> the product with changing requirements.
With version or not, if users want to update to the newer Kimchi/wok
version they will need to update their application to use the new API
otherwise they will keep back on old version.
All that because we don't (and will not!) maintain old versions - as I
said before.
I understand the scenario but it only makes sense while taking track on
different versions simultaneously - which is not our case.
If you need to do that for other matters, you suggest to maintain one
branch per version and keep tracking on which patch to apply on each branch.
> ----- Original message -----
> From: Aline Manera <alinefm(a)linux.vnet.ibm.com>
> Sent by: kimchi-devel-bounces(a)ovirt.org
> To: Chandra Shehkhar Reddy Potula <chandra(a)linux.vnet.ibm.com>,
> kimchi-devel(a)ovirt.org
> Cc:
> Subject: Re: [Kimchi-devel] [Proposal] Introducing the version in
> REST API URI for kimchi/ginger plugins
> Date: Fri, Aug 7, 2015 12:03 AM
>
>
> On 06/08/2015 07:41, Chandra Shehkhar Reddy Potula wrote:
>> Hi Aline,
>>
>> No need to mention explicitly, but this is very useful in case
>> where end users are exploiting functionality via REST API
>> directly and not UI way.
>
> I suppose end users know which version he/she is using, right? =)
>>
>> Regards
>> Chandra
>> On 08/06/2015 01:52 PM, Chandra Shehkhar Reddy Potula wrote:
>>> Hi Aline,
>>>
>>> Versioning helps you iterate faster and prevents invalid
>>> requests from hitting updated endpoints. It also helps smooth
>>> transitions over any major API version as you can continue to
>>> offer old API versions for a period of time. Definitely
>>> supporting the old version of API period of time while offering
>>> new functionality with newer version always give benefits and
>>> extra time for end user to adjust to new one.
>>>
>>> I see lot of products in the market are adapting versioning (see
>>> below link)
>>> http://www.lexicalscope.com/blog/2012/03/12/how-are-rest-apis-versioned/
>>>
>>> I do understand the concern of maintaining the version of the
>>> API endpoints , below are some of the links from Openstack,
>>> which talks about it.
>>> http://developer.openstack.org/api-ref.html
>>> https://wiki.openstack.org/wiki/VersionDiscovery
>>>
>>> Hope it make senses to you.
>>>
>>> Regards
>>> Chandra
>>> On 08/06/2015 12:04 AM, Aline Manera wrote:
>>>>
>>>> Hi Chandra,
>>>>
>>>> I don't see any benefit in adding the version in the URL.
>>>> Instead of that, it scares me on how we will maintain it.
>>>>
>>>> Once we move to wok and Kimchi as plugin, all the APIs will be
>>>> automatically updated so everything will be in the same page.
>>>>
>>>> Regards,
>>>> Aline Manera
>>>> On 17/07/2015 09:47, Chandra Sr Potula wrote:
>>>>>
>>>>> Hi Kimchi/Ginger Devel-Team,
>>>>>
>>>>> Thank you for creating WOK branch to separate the kimchi
>>>>> plugin from the base frame work. It is a great idea.
>>>>>
>>>>> Along with the separation of kimchi plugin looks like there is
>>>>> a transformation of REST API URIs as well. So thinking in
>>>>> those lines will it be good idea even to introduce version to
>>>>> the REST API URIs ?
>>>>>
>>>>> Let me take one REST API URI to convey clear on what I am
>>>>> talking about.
>>>>>
>>>>> To retrieve the host repository information, current URI is:
>>>>> "/plugins/kimchi/host/repositories".
>>>>>
>>>>> *Recommendation*:
>>>>> New host repository URI can look like :
>>>>> *"**/plugins/kimchi/v<version>/host/repositories" , *so that
>>>>> it is easy to maintain REST API future enhancements at the
>>>>> same time do not brake some body who is using the existing URI.
>>>>>
>>>>> Note* Adding version in the URI above is just an example and
>>>>> we could place the version in the URI best possible way.
>>>>>
>>>>> Thanks and Regards,
>>>>> *Chandra Shekhar Reddy Potula*
>>>>> Staff System Software Engineer
>>>>> IBM Systems & Technology Group, Systems Software Development
>>>>> System z Firmware Development
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>> *Phone:* 91-080-4066-0786 | *Mobile:* 91-973-1122-221
>>>>> *E-mail:*_chandra.shekhar@in.ibm.com_
>>>>> <mailto:chandra.shekhar@in.ibm.com>
>>>>> IBM
>>>>>
>>>>> ORR, Manyatha MD3 1F B247
>>>>> Bengaluru, Karnataka 560045
>>>>> India
>>>>>
>>>>> _______________________________________________
>>>>> Kimchi-devel mailing list
>>>>> Kimchi-devel(a)ovirt.org <mailto:Kimchi-devel@ovirt.org>
>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>>
>>>> _______________________________________________
>>>> Kimchi-devel mailing list
>>>> Kimchi-devel(a)ovirt.org <mailto:Kimchi-devel@ovirt.org>
>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>
>>> _______________________________________________
>>> Kimchi-devel mailing list
>>> Kimchi-devel(a)ovirt.org <mailto:Kimchi-devel@ovirt.org>
>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
>
9 years, 5 months
Re: [Kimchi-devel] Fwd: Proposal for moving functionality from Kimchi to Ginger
by Aline Manera
On 06/08/2015 14:49, Harshal Patil wrote:
> About 2) Basic info and 3)host stats below, do you think wok should
> actually display that info in tab or should it be just available only
> through API so that plugin developers can decide to display it in
> whichever way they prefer?
I have thought about it initially, but I don't agree any more as it
would break the idea of having on wok only what is needed to provide a
web server based on plugins.
Because that I proposed the common-host plugin to expose the APIs.
> ----- Original message -----
> From: Aline Manera <alinefm(a)linux.vnet.ibm.com>
> Sent by: kimchi-devel-bounces(a)ovirt.org
> To: Walter Niklaus <niklaus(a)linux.vnet.ibm.com>, Daniel Henrique
> Barboza <danielhb(a)linux.vnet.ibm.com>, Kimchi Devel
> <kimchi-devel(a)ovirt.org>
> Cc:
> Subject: Re: [Kimchi-devel] Fwd: Proposal for moving functionality
> from Kimchi to Ginger
> Date: Thu, Aug 6, 2015 9:01 PM
>
>
> Thanks, Walter, to send the scrum meeting summary here!
>
> Here are my thoughts on all that.
>
> First, let me clarify the proposal of each piece of cake! =)
>
> A) Wok is a *generic web server framework based on plugins*.
> By generic, I mean it should only expose APIs and
> functionalities required for a web server. Login, logout, plugins
> support, i18n support, message error handling and much more.
>
> B) Kimchi is a wok plugin for virtual machine management.
> And it is independent system platform: x86, Power or Z.
>
> C) Ginger is a wok plugin for host management.
> And it is independent system platform: x86, Power or Z.
>
> By now, it is all we have. So I'd like to concentrate our effort
> on it.
>
> Now thinking about which features from Kimchi Host tab can be
> moved to Ginger.
> Let do it item by item. The Host Tab is composed by:
>
> 1) Restart, Shutdown, Connect operations
> I don't see those functionalities close related to virtual
> machines management. So for me, it is fine and good to move them
> to Ginger.
>
> 2) Basic Information
> The kind of information may be very useful to user while
> manage virtual machine. Specially by the amount of memory and
> number of CPUs.
> With that information the user can properly balance his/her
> virtual machines configuration to have better system performance.
>
> 3) Host statistics
> The same I described on item 2.
>
> 4) Software Update
> I don't see this functionality close related to virtual
> machines management. So for me, it is fine and good to move them
> to Ginger.
>
> 5) Repository management
> I don't see this functionality close related to virtual
> machines management. So for me, it is fine and good to move them
> to Ginger.
>
> 6) Debug reports
> This functionality may be interesting for virtual machine
> management when some of them represents a problem or bad performance.
> So user can easily grab the system logs to check what is going
> wrong.
>
> So if no one opposes, we can start moving 1, 4 and 5 to Ginger.
> As we have 2 different open source communities we need to
> coordinate that work. Initially the patch for Kimchi will be for
> removing those features and to Ginger to add them.
> The Kimchi patch must be simpler but it will require more work on
> Ginger side.
>
> About 2, 3 and 6: I really understand how those information are
> important for virtual machine management and also for host
> management, i.e, Kimchi and Ginger.
> (And I hope you all do the same :-) )
>
> So in my mind, we are discussing a solution to expose those
> information on both, Kimchi and Ginger, without making it
> duplicated somehow to user.
>
> As per discussion (see item A), wok is a generic framework and
> should not handle those kind of APIs. (Agree?)
> And also it should not have any default plugin (otherwise, we
> could continue having Kimchi as default without the need to have
> the wok framework)
> While loading wok without any plugin, it should display a simple
> page "Welcome to wok" or something like that but without any
> functionality.
>
> So my proposal is to create a new and simple plugin (let's call it
> as common-host plugin) that expose those APIs without any UI.
>
> Kimchi and Ginger will have a dependency on this common-host
> plugin and will provide the proper UI for it.
>
> To do not duplicate information while loading Kimchi and Ginger
> together, I propose to add a smart logic for it:
>
> - Kimchi will always load the Host tab with the common-host plugin
> (as it is today).
> - Ginger will load the common-host plugin *only and if only* it is
> running standalone.
>
> What do you think about it?
>
> Regards,
> Aline Manera
> On 06/08/2015 11:15, Walter Niklaus wrote:
>> Picking up the discussion from the Scrum meeting about where
>> (which plugin) certain functionalities should be.
>>
>> To make sure we don't miss this aspect, I'm re-iterating on the
>> high level use cases.
>> Currently I see the following major usecases now and in the near
>> future (next year):
>> 1. A user wants to perform base Linux management only.
>> - here he needs all the generic Host-Management
>> functionality + the platform specific stuff like:
>> Power-FW code update, Energy Management on Power or
>> IO-Device Management on System z
>> 2. A user wants to manage KVM Virtual Machines.
>> - his primary scope are VMs. How much of the Host and
>> Platform specific Management functionality is required here ?
>> 3. A user wants to manage Containers.
>> - his primary scope are Container. How much of the Host
>> and Platform specific Management functionality is required here ?
>> 4. A user wants to manage Containers and KVM Virtual Machines .
>> - his primary scope are Container and VMs. How much of the
>> Host and Platform specific Management functionality is required
>> here ?
>>
>> Our current discussion now is for the usecases 2,3 and 4: How
>> much of the Host and Platform specific Management functionality
>> is required and what's the best way to organize and package it.
>> One possibility could be to have all Host-Management
>> functionality looked at being part of the default/basic
>> functionset and delivery and have the Platform specifc
>> functionality as optional plugins. The disadvantage of this
>> approach would be that all the following functionality:
>> Basic Information, System Statistics, Network (Host NICs,DNS
>> ...), Storage/SAN (Host Storage), User Management, Configuration
>> Backup, Software Updates, Repositories, Debug Reports would be
>> present in the Container and VM usecases by default.
>> Do we know what a user really needs and wants in the usecases 2,3
>> and 4 ? I guess this depends to a large degree of the toolset
>> she/he is using beside Kimchi and Ginger. If there is no other
>> tooling available she/he may be happy about the shipped
>> functionset, but for sure there are other situation where she/he
>> may not be interested in some of the functionality.
>>
>> What could be the reasons a user would want to pick selectively ?
>> a. functionality not required or maybe even conflicting with
>> some other tooling: for example Software Updates
>> are managed from some central instance
>> b. installing a reduced functionset could reduce the external
>> package dependencies and could reduce the amount of updates
>> c. simplification on the UI by eliminating unrequired stuff
>>
>> Ideally the user could choose on an individual functionality base
>> and configure the tool based on his needs.
>> I guess satisfying the reasons a. and c. from above could be
>> implemented via UI customisation even on an individual
>> Kimchi/Ginger user base.
>> Reason b. can be probably achieved only by segregating the set of
>> fuctionality in separate plugins.
>>
>>
>> On 04.08.2015 17:26, Walter Niklaus wrote:
>>> ... Daniel sorry for the duplicate send, I missed to reply to
>>> all so the mail didn't go to the mailing list.
>>> On 04.08.2015 14:39, Daniel Henrique Barboza wrote:
>>>>
>>>> On 08/04/2015 04:56 AM, Walter Niklaus wrote:
>>>>> Hi Daniel,
>>>>>
>>>>> sorry for missing the thread where this topic was discussed.
>>>>>
>>>>> I can fully understand the point about Basic Information and
>>>>> System Statistics being relevant for Virtualization management
>>>>> as well and I like the idea of potentially making it part of
>>>>> the base framework because they would be very usefull for
>>>>> other plugins, like Container-Management as well.
>>>>> The interesting question is then if some of the other
>>>>> functions wouldn't make sense to be part of the basic
>>>>> framework as well. Debug reports would be a classical
>>>>> candidate from my point of view, but wouldn't some of the
>>>>> other functions be usefull in the base as well ?
>>>>
>>>> If we're really going in that approach (putting basic features
>>>> in WoK), I agree. We would have to
>>>> discuss each existing feature and evaluate if it belongs to
>>>> kimchi, ginger or wok.
>>>
>>> I guess we really need to have a discussion on the individual
>>> features but I would like to start this one from a user
>>> requirements point of view.
>>> Currently I see the following major usecases now and in the near
>>> feature:
>>> 1. A user wants to perform base Linux management only.
>>> 2. A user wants to manage KVM Virtual Machines.
>>> 3. A user wants to manage Containers.
>>> 4. A user wants to manage Containers and KVM Virtual Machines .
>>>
>>> For the usecases 2, 3 and 4 the user needs usecase 1 as well in
>>> order to prepare and manage the Host machine.
>>>
>>> I'm not proposing to make the Linux Host Management part of the
>>> base framework because we just separated out Kimchi of it, but I
>>> think it makes a lot of sense to deliver the Host Management
>>> plugin by default with the base framework.
>>>>>
>>>>> Looking at the problem form a different angle: wouldn't it
>>>>> make sense to package and deliver the base framework with the
>>>>> Ginger plugin by default because the Host-functionality Ginger
>>>>> is offering would be usefull for the other plugins like
>>>>> Virtualization and Containers ?
>>>>>
>>>>> What I missed in my previous mail is the aspect about platform
>>>>> specific functionality. This functionality, like PPC firmware
>>>>> update or IO-device management for Linux on z should be made
>>>>> available as individual plugins.
>>>>
>>>> At this moment Ginger can handle multi-arch features fairly
>>>> well. For example, Firmware
>>>> Update does not appear when running the plug-in in an Intel
>>>> computer. The feature you mentioned,
>>>> IO-device management for Linux on Z, would be available only
>>>> when running Ginger in a Linux
>>>> for Z host.
>>>>
>>>> There's absolutely nothing holding you from making a brand new
>>>> plug-in for the Z features instead
>>>> of adding them to Ginger, but it is important to know that
>>>> Ginger is designed for these scenarios.
>>>> You can even create a new UI tab in Ginger, something like 'Z
>>>> management' which would contain all Z related features. This
>>>> tab would only appear in a Linux on Z host. From the UI
>>>> perspective it looks
>>>> like a brand new plug-in working together with Ginger common
>>>> features in the 'Administration' tab.
>>>>>
>>>>> Please let me know what you think about this option.
>>>>>
>>>>> Thanks,
>>>>> Walter.
>>>>>
>>>>> On 03.08.2015 18:51, Daniel Henrique Barboza wrote:
>>>>>> Hi Walter,
>>>>>>
>>>>>> We've had this discussion with the community a few months ago
>>>>>> in the thread
>>>>>>
>>>>>> "[RFC] Moving some features of Host tab to Ginger"
>>>>>>
>>>>>> And we agreed to start it by moving only Software Update,
>>>>>> Repositories and
>>>>>> Debug Reports from Kimchi to Ginger.
>>>>>>
>>>>>> The Basic Information and System Statistics can't be taken
>>>>>> away from Kimchi because there
>>>>>> are relevant information for the creation of VMs there, such
>>>>>> as Memory Available. But I agree
>>>>>> that these information fits nicely in Ginger too.
>>>>>>
>>>>>> One alternative (just came in my head now) is to move these
>>>>>> "neutral" functions
>>>>>> to a "Basic System Info" in WoK. That way both Kimchi and
>>>>>> Ginger users can access
>>>>>> the information.
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>
>>>>>> Daniel
>>>>>> On 08/03/2015 12:15 PM, Walter Niklaus wrote:
>>>>>>>
>>>>>>> After separating out Kimchi as an indvidual plugin from the base
>>>>>>> framework it would be great to have a clean separation
>>>>>>> between Host- and
>>>>>>> Virtualization Management functions. I'm planning to work on
>>>>>>> this topic
>>>>>>> in the next few weeks and have prepared a proposal of the
>>>>>>> functionsplit.
>>>>>>> Plugin functionality:
>>>>>>> - Ginger:
>>>>>>> - Basic Information
>>>>>>> - System Statistics
>>>>>>> - Network (Host NICs)
>>>>>>> - Storage/SAN (Host Storage)
>>>>>>> - User Management
>>>>>>> - Configuration Backup
>>>>>>> - Software Updates
>>>>>>> - Repositories
>>>>>>> - Debug Reports
>>>>>>> - PPC related functions: Firmware Update & Power
>>>>>>> Management
>>>>>>> - Kimchi:
>>>>>>> - Templates
>>>>>>> - Guests
>>>>>>> - Networks (virtual)
>>>>>>> - Storage (Pools for VMs)
>>>>>>>
>>>>>>> Since there are plans to restructure the UI for one of the next
>>>>>>> releases, I'm proposing to do only some minimal investments in
>>>>>>> reflecting this new finctionsplit. Therefore I'm proposing
>>>>>>> to make the
>>>>>>> Host tab as the one and only Tab for Ginger and move
>>>>>>> everything from the
>>>>>>> Administration Tab into the Host Tab. This would be just an
>>>>>>> intermediate solution till we implement the new UI design.
>>>>>>> Please see
>>>>>>> the attached PDF.
>>>>>>> Thanks in advance for your feedback.
>>>>>>>
>>>>>>> Walter.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Kimchi-devel mailing list
>>>>>>> Kimchi-devel(a)ovirt.org <mailto:Kimchi-devel@ovirt.org>
>>>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>>>>
>>>>>> _______________________________________________
>>>>>> Kimchi-devel mailing list
>>>>>> Kimchi-devel(a)ovirt.org <mailto:Kimchi-devel@ovirt.org>
>>>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel(a)ovirt.org <mailto:Kimchi-devel@ovirt.org>
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
>
9 years, 5 months
Re: [Kimchi-devel] adding '/auth' for authentication
by Aline Manera
On 06/08/2015 14:27, Harshal Patil wrote:
> This is all cool. So when you talk about wok being the base web
> framework where it provides basic services like login, logout, plugin
> support, i18n etc. to plugin developers do you think adding 'auth' as
> another service provided by wok to plugin developers makes any sense?
> Like you mentioned on IRC during scrum meeting, someone might even
> write a wok plugin for makeup tips and you are totally fine with it.
> Do you think if we provide an easy way for that developer to
> authenticate his/her plugin's users quickly and easily? Something
> other python web frameworks like flask already provide
> (http://flask.pocoo.org/snippets/category/authentication/), or even
> cherrypy for that matter
> (http://tools.cherrypy.org/wiki/AuthenticationAndAccessRestrictions).
> They provide nice decorators which plugin developers can use in their
> handlers (exposed in the language of cherrypy) methods.
> We could provide a nice wrapper around those ideas for authentication
> using say, PAM, NIS+, LDAP etc.
> What do you say?
Wait! Wait! We are talking on different topics.
Wok already supports PAM and LDAP authentication. You can properly
configure which method to use in your wok.conf file.
To do the authentication on server side we have the APIs /login and
/logout - to initialize and finalize a web server session to an user.
If we are talking about authentication methods, the API already exists.
What I and Lucio were talking is how to check user has a valid session
for each AJAX request - for that you should add the 'wok'-robot' header
to your AJAX calls.
> ----- Original message -----
> From: Aline Manera <alinefm(a)linux.vnet.ibm.com>
> To: luciojhc(a)linux.vnet.ibm.com, Harshal Patil/India/IBM@IBMIN,
> kimchi-devel(a)ovirt.org
> Cc:
> Subject: Re: [Kimchi-devel] adding '/auth' for authentication
> Date: Thu, Aug 6, 2015 6:27 PM
>
> On 05/08/2015 18:02, Lucio Correia wrote:
> > On 08/05/2015 04:27 PM, Aline Manera wrote:
> >>
> >>
> >> On 05/08/2015 14:56, Lucio Correia wrote:
> >>> Hi Harshal,
> >>>
> >>> On 08/02/2015 01:45 PM, Harshal Patil wrote:
> >>>> Hi,
> >>>> In the 'wok' branch there isn't anything to detect if the
> session has
> >>>> timed out on the browser side. On the other hand, on master
> (kimchi)
> >>>> there is '/vms' endpoint called every 5 seconds which kinda
> takes care
> >>>> of making sure the user is indeed logged in.
> >>>> So I was wondering, if no one is already working on it, to
> introduce a
> >>>> '/auth' endpoint which we can poll every 5 seconds using ajax and
> >>>> based
> >>>> on the response status code we can either redirect to login
> page or
> >>>> just
> >>>> stay on the same page. This is useful in 'wok' because there
> isn't any
> >>>> '/vms' endpoint which existed in master (kimchi) by default.
> >>>> I can submit a patch for review if this sounds good so far.
> Also, if
> >>>> there is a better way of doing it, I would love to hear about it.
> >>>> Harshal
> >>>>
> >>>>
> >>>
> >>> The 10-minutes time out is still working with wok branch. But
> it is
> >>> only verified if you leave it in "Host" or "Guests" tab. Other
> tabs'
> >>> APIs don't send "wok-robot" in headers.
> >>>
> >>> Your proposal is good, you will need to send "wok-robot" in
> '/auth'
> >>> headers, and remove the "wok-robot" from kimchi plugin's Host and
> >>> Guests API headers.
> >>
> >> Why do you need a API /auth to check the user is logged?
> Shouldn't the
> >> "wok-robot" header be enough to do that?
> >> Otherwise, we will increase significantly the number of the
> requests, as
> >> the real request would be send after a /auth request.
> >>
> >
> > Good point Aline, we really don't need /auth. If we want timeout
> > checked for every request, I see two alternatives:
> > * drop wok-robot verification from check_auth_session() in
> > src/wok/auth.py.
> > * add wok-robot headers to requestJSON() in wok.api.js.
>
> I prefer the second alternative. The 'wok-robot' header was created to
> distinguish AJAX requests from user requests.
>
> >
> > But I don't know why currently only hosts and guests tab use
> wok-robot.
> >
>
> Because only those tabs have logic to pool the request every X
> seconds.
> In fact, we need to add this to every tab to keep consistence and
> automatically logout user when session expires.
>
>
9 years, 5 months
[PATCH 1/1] Enabling help page for wok base. This commit supports en_US only.
by sureshab＠linux.vnet.ibm.com
From: Suresh Babu Angadi <sureshab(a)linux.vnet.ibm.com>
Signed-off-by: Suresh Babu Angadi <sureshab(a)linux.vnet.ibm.com>
---
configure.ac | 2 +
src/wok/config.py.in | 5 +
ui/js/src/wok.main.js | 9 +-
ui/pages/Makefile.am | 2 +-
ui/pages/help/Makefile.am | 34 +++++++
ui/pages/help/dita-help.xsl | 26 +++++
ui/pages/help/en_US/Makefile.am | 23 +++++
ui/pages/help/en_US/wokhelp.dita | 27 +++++
ui/pages/help/wok.css | 208 +++++++++++++++++++++++++++++++++++++++
9 files changed, 333 insertions(+), 3 deletions(-)
create mode 100644 ui/pages/help/Makefile.am
create mode 100644 ui/pages/help/dita-help.xsl
create mode 100644 ui/pages/help/en_US/Makefile.am
create mode 100644 ui/pages/help/en_US/wokhelp.dita
create mode 100644 ui/pages/help/wok.css
diff --git a/configure.ac b/configure.ac
index 47c2e6c..ee4d793 100644
--- a/configure.ac
+++ b/configure.ac
@@ -115,6 +115,8 @@ AC_CONFIG_FILES([
ui/libs/themes/base/Makefile
ui/libs/themes/base/images/Makefile
ui/pages/Makefile
+ ui/pages/help/Makefile
+ ui/pages/help/en_US/Makefile
ui/pages/websockify/Makefile
contrib/Makefile
contrib/DEBIAN/Makefile
diff --git a/src/wok/config.py.in b/src/wok/config.py.in
index 5ffa936..c158a75 100644
--- a/src/wok/config.py.in
+++ b/src/wok/config.py.in
@@ -142,6 +142,11 @@ class WokConfig(dict):
'/wok-ui.html': {
'tools.wokauth.on': True
},
+ '/help': {
+ 'tools.staticdir.on': True,
+ 'tools.staticdir.dir': '%s/ui/pages/help' % paths.prefix,
+ 'tools.nocache.on': True
+ }
}
def __init__(self):
diff --git a/ui/js/src/wok.main.js b/ui/js/src/wok.main.js
index f4c9940..3dd76b8 100644
--- a/ui/js/src/wok.main.js
+++ b/ui/js/src/wok.main.js
@@ -349,7 +349,12 @@ wok.checkHelpFile = function(path) {
wok.openHelp = function(e) {
var tab = $('#nav-menu a.current');
- var url = $(tab).parent().find("input[name='helpPath']").val();
- window.open(url, "Wok Help");
+ if (tab.length == 0 ){
+ window.open("help/en_US/wokhelp.html","Wok Help")
+ }
+ else {
+ var url = $(tab).parent().find("input[name='helpPath']").val();
+ window.open(url, "Wok Help");
+ }
e.preventDefault();
};
diff --git a/ui/pages/Makefile.am b/ui/pages/Makefile.am
index 68f4c92..b3f5c2e 100644
--- a/ui/pages/Makefile.am
+++ b/ui/pages/Makefile.am
@@ -15,7 +15,7 @@
# See the License for the specific language governing permissions and
# limitations under the License.
-SUBDIRS = websockify
+SUBDIRS = websockify help
htmldir = $(datadir)/wok/ui/pages
diff --git a/ui/pages/help/Makefile.am b/ui/pages/help/Makefile.am
new file mode 100644
index 0000000..0dc8d9f
--- /dev/null
+++ b/ui/pages/help/Makefile.am
@@ -0,0 +1,34 @@
+# Copyright IBM Corp, 2014
+#
+# This library is free software; you can redistribute it and/or
+# modify it under the terms of the GNU Lesser General Public
+# License as published by the Free Software Foundation; either
+# version 2.1 of the License, or (at your option) any later version.
+#
+# This library is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# Lesser General Public License for more details.
+#
+# You should have received a copy of the GNU Lesser General Public
+# License along with this library; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+
+SUBDIRS = en_US
+
+DITA_HTML_FILES = $(patsubst %.dita,%.html,$(wildcard */*.dita))
+HTML_FILES = $(if $(DITA_HTML_FILES), $(DITA_HTML_FILES), $(wildcard */*.html))
+DITA_XSL_FILE = dita-help.xsl
+
+EXTRA_DIST = $(DITA_XSL_FILE)
+
+helpdir = $(datadir)/wok/ui/pages/help
+
+dist_help_DATA = wok.css
+
+all: $(HTML_FILES) $(wildcard */*.dita)
+
+%.html: %.dita $(DITA_XSL_FILE)
+ xsltproc -o $@ $(DITA_XSL_FILE) $<
+
+CLEANFILES = $(HTML_FILES)
\ No newline at end of file
diff --git a/ui/pages/help/dita-help.xsl b/ui/pages/help/dita-help.xsl
new file mode 100644
index 0000000..fb49855
--- /dev/null
+++ b/ui/pages/help/dita-help.xsl
@@ -0,0 +1,26 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<xsl:stylesheet version="1.0"
+ xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+ xmlns="http://www.w3.org/1999/xhtml">
+ <xsl:output method="xml" indent="yes" encoding="UTF-8" />
+
+ <xsl:template match="/">
+ <html>
+ <head>
+ <title><xsl:value-of select="/cshelp/title" /></title>
+ <meta charset="UTF-8" />
+ <link rel="shortcut icon" href="../../images/logo.ico" />
+ <link rel="stylesheet" type="text/css" href="../wok.css" />
+ </head>
+ <body>
+ <xsl:apply-templates select="//cshelp" />
+ </body>
+ </html>
+ </xsl:template>
+
+ <xsl:template match="cshelp">
+ <h1><xsl:value-of select="title" /></h1>
+ <p class="shortdesc"><xsl:value-of select="shortdesc" /></p>
+ <p class="csbody"><xsl:copy-of select="csbody/node()" /></p>
+ </xsl:template>
+</xsl:stylesheet>
diff --git a/ui/pages/help/en_US/Makefile.am b/ui/pages/help/en_US/Makefile.am
new file mode 100644
index 0000000..b1e807d
--- /dev/null
+++ b/ui/pages/help/en_US/Makefile.am
@@ -0,0 +1,23 @@
+# Copyright IBM Corp, 2014
+#
+# This library is free software; you can redistribute it and/or
+# modify it under the terms of the GNU Lesser General Public
+# License as published by the Free Software Foundation; either
+# version 2.1 of the License, or (at your option) any later version.
+#
+# This library is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# Lesser General Public License for more details.
+#
+# You should have received a copy of the GNU Lesser General Public
+# License along with this library; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+
+en_US_helpdir = $(datadir)/wok/ui/pages/help/en_US
+
+dist_en_US_help_DATA = $(wildcard *.html) $(NULL)
+
+EXTRA_DIST = $(wildcard *.dita)
+
+CLEANFILES = $(wildcard *.html)
\ No newline at end of file
diff --git a/ui/pages/help/en_US/wokhelp.dita b/ui/pages/help/en_US/wokhelp.dita
new file mode 100644
index 0000000..582e47b
--- /dev/null
+++ b/ui/pages/help/en_US/wokhelp.dita
@@ -0,0 +1,27 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!--Arbortext, Inc., 1988-2011, v.4002-->
+<!DOCTYPE cshelp PUBLIC "-//IBM//DTD DITA CSHelp//EN"
+ "..\dtd\cshelp.dtd">
+<?Pub Sty _display FontColor="red"?>
+<?Pub Inc?>
+<!--This DITA specialized document type is not supported by the Authoring Tools development team.
+For support please see:
+https://w3.opensource.ibm.com/projects/dita-cshelp/-->
+<cshelp id="wokbase" xml:lang="en-us">
+<title>Wok (Webserver Originated from Kimchi)</title>
+<shortdesc>Wok is a cherrypy-based web framework with HTML5 support that is extended by plugins which expose functionality through REST APIs.</shortdesc>
+<csbody>
+<p>Currently available plugins are Kimchi (Virtualization Management) and Ginger (System Administration).
+Wok comes with a sample plugin for education purposes.<ul>
+<li><uicontrol>Download Kimchi : </uicontrol>
+<a href="https://github.com/kimchi-project/kimchi/tree/wok"
+target="_blank" >https://github.com/kimchi-project/kimchi/tree/wok</a>
+</li>
+<li><uicontrol>Download Ginger : </uicontrol>
+<a href="https://github.com/kimchi-project/ginger/tree/ginger_wok"
+target="_blank" >https://github.com/kimchi-project/ginger/tree/ginger_wok</a>
+</li>
+</ul>
+</p>
+</csbody>
+</cshelp>
diff --git a/ui/pages/help/wok.css b/ui/pages/help/wok.css
new file mode 100644
index 0000000..32fae4a
--- /dev/null
+++ b/ui/pages/help/wok.css
@@ -0,0 +1,208 @@
+/*
+ * Project Kimchi
+ *
+ * Copyright IBM, Corp. 2014
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+BODY {
+ background: #FFFFFF;
+ margin-bottom: 1em;
+ margin-left: .5em;
+}
+
+bold {
+ font-weight: bold;
+}
+
+boldItalic {
+ font-weight: bold;
+ font-style: italic;
+}
+
+italic {
+ font-style: italic;
+}
+
+underlined {
+ text-decoration: underline;
+}
+
+uicontrol {
+ font-weight: bold;
+}
+
+filepath {
+ font-family: monospace, monospace;
+}.option {
+ font-family: monospace, monospace;
+}
+
+cmdname {
+ font-weight: bold;
+ font-family: monospace, monospace;
+}
+
+.defparmname {
+ font-weight: bold;
+ text-decoration: underline;
+ font-family: monospace, monospace;
+}
+
+.kwd {
+ font-weight: bold;
+}
+
+.defkwd {
+ font-weight: bold;
+ text-decoration: underline;
+}
+
+var {
+ font-style : italic;
+}
+
+strongwintitle {
+ font-weight : bold;
+}
+
+parmname {
+ font-weight: bold;
+ font-family: monospace, monospace;
+ white-space: nowrap;
+}
+
+code {
+ font-family: monospace, monospace;
+}
+
+pre {
+ font-family: monospace, monospace;
+}
+
+CITE {
+ font-style: italic;
+}
+
+EM {
+ font-style: italic;
+}
+
+STRONG {
+ font-weight: bold;
+}
+
+VAR {
+ font-style: italic;
+}
+
+dt {
+ font-weight: bold;
+}
+
+/***********************************************************
+ * Basic fonts
+ ***********************************************************/
+body,
+td,
+th,
+caption {
+ font-family: Verdana, Arial, Helvetica, sans-serif;
+ font-size: 10pt;
+}
+
+pre, code {
+ font-family: MS Courier New, Courier, monospace;
+}
+
+h1, h2, h3 {
+ font-size: 12pt;
+ font-weight: bold;
+ color: #336699;
+}
+
+h4 {
+ font-size: 10pt;
+ font-weight: bold;
+ color: #336699;
+}
+
+/***********************************************************
+ * Basic indents, padding, and margin
+ ***********************************************************/
+body {
+ color: black;
+ background-color: white;
+ margin: 0;
+ padding-top: 0.2em;
+ padding-left: 0.6em;
+ padding-right: 0.2em;
+ padding-bottom: 1em;
+}
+
+h1,
+h2,
+h3,
+h4,
+h5,
+h6 {
+ padding: 0;
+ margin-top: 1em;
+ margin-bottom: 0.75em;
+ margin-left: 0;
+ margin-right: 0;
+}
+
+address,
+dl,
+li,
+p {
+ padding: 0;
+ margin-top: 0.75em;
+ margin-bottom: 0.75em;
+ margin-left: 0;
+ margin-right: 0;
+ line-height: 125%;
+}
+
+td dl {
+ margin-left: 2em;
+}
+
+pre {
+ padding: 0;
+ margin-top: 0.75em;
+ margin-bottom: 0.75em;
+ margin-left: 2em;
+ margin-right: 0;
+}
+
+ol,
+ul {
+ padding: 0;
+ margin-top: 0.75em;
+ margin-bottom: 0.75em;
+ margin-left: 2.00em;
+ margin-right: 0;
+}
+
+dd {
+ margin-left: 3.00em;
+ margin-top: 0.75em;
+ margin-bottom: 0.75em;
+}
+
+dt {
+ margin-left: 1.00em;
+ margin-top: 0.75em;
+}
--
2.1.0
9 years, 5 months
[PATCH v2] Set default VM template memory to 2048 in Power
by dhbarboza82＠gmail.com
From: Daniel Henrique Barboza <dhbarboza82(a)gmail.com>
There are no official Kimchi support for VMs running with under 2048Mb
of RAM in Power systems. This patch set the default memory of templates
created in Power hosts to 2048, instead of 1280.
This patch also adds the default memory for x86_64 arch to the
template_specs dict of osinfo.py instead of hardcoding the value in the
_get_tmpl_defaults() function.
Signed-off-by: Daniel Henrique Barboza <dhbarboza82(a)gmail.com>
---
src/kimchi/osinfo.py | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/src/kimchi/osinfo.py b/src/kimchi/osinfo.py
index 78eb828..f8ab7da 100644
--- a/src/kimchi/osinfo.py
+++ b/src/kimchi/osinfo.py
@@ -35,37 +35,39 @@ SUPPORTED_ARCHS = {'x86': ('i386', 'i686', 'x86_64'),
template_specs = {'x86': {'old': dict(disk_bus='ide',
- nic_model='e1000', sound_model='ich6'),
+ nic_model='e1000', sound_model='ich6',
+ memory=1024),
'modern': dict(disk_bus='virtio',
nic_model='virtio',
- sound_model='ich6')},
+ sound_model='ich6',
+ memory=1024)},
'power': {'old': dict(disk_bus='scsi',
nic_model='spapr-vlan',
cdrom_bus='scsi',
kbd_type="kbd",
kbd_bus='usb', mouse_bus='usb',
- tablet_bus='usb', memory=1280),
+ tablet_bus='usb', memory=2048),
'modern': dict(disk_bus='virtio',
nic_model='virtio',
cdrom_bus='scsi',
kbd_bus='usb',
kbd_type="kbd",
mouse_bus='usb', tablet_bus='usb',
- memory=1280)},
+ memory=2048)},
'ppc64le': {'old': dict(disk_bus='virtio',
nic_model='virtio',
cdrom_bus='scsi',
kbd_bus='usb',
kbd_type="keyboard",
mouse_bus='usb', tablet_bus='usb',
- memory=1280),
+ memory=2048),
'modern': dict(disk_bus='virtio',
nic_model='virtio',
cdrom_bus='scsi',
kbd_bus='usb',
kbd_type="keyboard",
mouse_bus='usb', tablet_bus='usb',
- memory=1280)}}
+ memory=2048)}}
custom_specs = {'fedora': {'22': dict(video_model='qxl')}}
@@ -107,7 +109,6 @@ def _get_tmpl_defaults():
# Create dict with default values
tmpl_defaults = defaultdict(dict)
tmpl_defaults['main']['networks'] = ['default']
- tmpl_defaults['main']['memory'] = 1024
tmpl_defaults['storage']['pool'] = 'default'
tmpl_defaults['storage']['disk.0'] = {'size': 10, 'format': 'qcow2'}
tmpl_defaults['processor']['cpus'] = 1
--
2.4.3
9 years, 5 months
[PATCH] Setting default memory of PPC to 2048
by dhbarboza82＠gmail.com
From: Daniel Henrique Barboza <dhbarboza82(a)gmail.com>
At this moment Kimchi for Power systems does not support guests
created with less that 2Gb of RAM. This patch set the default
Power template to reflect it.
Any user defined setting in template.conf will overwrite this
default. This is intended. The user must have the final
word in the customization of his/her VM templates.
Signed-off-by: Daniel Henrique Barboza <dhbarboza82(a)gmail.com>
---
src/kimchi/osinfo.py | 26 +++++++++++++++-----------
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/src/kimchi/osinfo.py b/src/kimchi/osinfo.py
index 78eb828..6506f2d 100644
--- a/src/kimchi/osinfo.py
+++ b/src/kimchi/osinfo.py
@@ -44,28 +44,28 @@ template_specs = {'x86': {'old': dict(disk_bus='ide',
cdrom_bus='scsi',
kbd_type="kbd",
kbd_bus='usb', mouse_bus='usb',
- tablet_bus='usb', memory=1280),
+ tablet_bus='usb', memory=2048),
'modern': dict(disk_bus='virtio',
nic_model='virtio',
cdrom_bus='scsi',
kbd_bus='usb',
kbd_type="kbd",
mouse_bus='usb', tablet_bus='usb',
- memory=1280)},
+ memory=2048)},
'ppc64le': {'old': dict(disk_bus='virtio',
nic_model='virtio',
cdrom_bus='scsi',
kbd_bus='usb',
kbd_type="keyboard",
mouse_bus='usb', tablet_bus='usb',
- memory=1280),
+ memory=2048),
'modern': dict(disk_bus='virtio',
nic_model='virtio',
cdrom_bus='scsi',
kbd_bus='usb',
kbd_type="keyboard",
mouse_bus='usb', tablet_bus='usb',
- memory=1280)}}
+ memory=2048)}}
custom_specs = {'fedora': {'22': dict(video_model='qxl')}}
@@ -89,6 +89,16 @@ icon_available_distros = [icon[5:-4] for icon in glob.glob1('%s/images/'
% paths.ui_dir, 'icon-*.png')]
+def _get_arch():
+ for arch, sub_archs in SUPPORTED_ARCHS.iteritems():
+ if os.uname()[4] in sub_archs:
+ return arch
+
+
+def _get_default_template_mem(host_arch):
+ return template_specs[host_arch]['modern'].get('memory', 1024)
+
+
def _get_tmpl_defaults():
"""
ConfigObj returns a dict like below when no changes were made in the
@@ -107,7 +117,7 @@ def _get_tmpl_defaults():
# Create dict with default values
tmpl_defaults = defaultdict(dict)
tmpl_defaults['main']['networks'] = ['default']
- tmpl_defaults['main']['memory'] = 1024
+ tmpl_defaults['main']['memory'] = _get_default_template_mem(_get_arch())
tmpl_defaults['storage']['pool'] = 'default'
tmpl_defaults['storage']['disk.0'] = {'size': 10, 'format': 'qcow2'}
tmpl_defaults['processor']['cpus'] = 1
@@ -157,12 +167,6 @@ def _get_tmpl_defaults():
defaults = _get_tmpl_defaults()
-def _get_arch():
- for arch, sub_archs in SUPPORTED_ARCHS.iteritems():
- if os.uname()[4] in sub_archs:
- return arch
-
-
def get_template_default(template_type, field):
host_arch = _get_arch()
# Assuming 'power' = 'ppc64le' because lookup() does the same,
--
2.4.3
9 years, 5 months
Problems using Kimchi inside a VNC session
by Ramon Medeiros
Hi,
did anyone hit an issue using kimchi inside a VNC session?
I tried to use Kimchi inside it, and i can't type on the novnc console.
--
Ramon Nunes Medeiros
Kimchi Developer
Linux Technology Center Brazil
IBM Systems & Technology Group
Phone : +55 19 2132 7878
ramonn(a)br.ibm.com
9 years, 5 months
[Clarification] WOK branch UI development
by Chandra Sr Potula
Hi Kimchi Devel-team,
There was good amount of discussion on using of bootstrap or foundation 5
for the new-ui development for WOK branch in the IRC (on 2015-07-08).
Question I have on this topic:
1. Are we experimenting with bootstrap and decide in the near future on
technology for new-ui development or bootstrap is the way to go for UI ?
2. Also are we applying the design thinking as well when it comes to new-ui
development for kimchi?
3. Do we have time line to accomplish this transformation ?
We have seen few UI issues in the WOK branch after separation of kimchi
plugin from base frame work (Issues #704-709). I see all of them labeled as
'wok' now. So for short time is it worth while to fix these issues ? If so,
is there a way assign these to my team members or some body help us in
fixing these issues ?
Thanks in advance,
Regards
Chandra
9 years, 5 months
[DOUBT] How to use setTimeout correctly
by Ramon Medeiros
Hi team,
i was trying to cache 2 objects, but they came from a HTTP request, and
took some time to download it. I was unable to use the function
setTimeout while calling this function:
kimchi.getPCIDeviceCompanions(kimchi.hostPCIs[i].name,
setTimeout(function(result) {
kimchi.deviceCompanions[kimchi.hostPCIs[i].name] = result;
},5000));
}
The function kimchi.getPCIDeviceCompanions usually takes 2s to finish.
--
Ramon Nunes Medeiros
Kimchi Developer
Linux Technology Center Brazil
IBM Systems & Technology Group
Phone : +55 19 2132 7878
ramonn(a)br.ibm.com
9 years, 5 months
