Re: Improving descriptions in the API reference pages
Erik, Nick Brody is an alias from some american soap or something, so it is probably a temporary account that's been hacked. On Mon, Aug 3, 2015 at 1:48 PM, Erik Weber terbol...@gmail.com wrote: Hi Nick, If that is indeed your name, and not an alias. This is not the first time you have answered with short, at times also provocative, unnecessary messages. I, and probably more, would appreciate if you held these kind of messages to yourself, instead of polluting this list with garbage. -- Erik On Mon, Aug 3, 2015 at 12:57 PM, Nick Brody nickbrody2...@gmail.com wrote: Whatever On Mon, Aug 3, 2015 at 3:28 AM, Rajsekhar K rajsekharkpa...@gmail.com wrote: Hi, All, This is part of our effort to improve user experience of Cloudstack API reference pages. Majority of the CloudStack API reference pages do not adequately describe the usage of the parameters associated with them. Many of these parameters contain only a single line description, which does not really enhance the user's experience with these APIs. As part of this content improvement effort, I need to improve the description, add information on the format, and an example on how to use the parameter. Please find attached the improved content for the migrateto parameter in the 'migrateVirtualMachineWithVolume' API reference page as an example. I think I can take the description for the migrateto parameter as a base and improve the descriptions of the parameters in the CloudStack API reference pages. As an initial step, I have identified the following 20 API functions and I am planning to improve the description of the parameters available in their reference pages: * listAccounts * listCapacity * listLoadBalancerRules * listNetworks * listPublicIpAddresses * listSnapshots * listTemplates * listVirtualMachines * listVolumes * listZones * stopVirtualMachine * associateIPAddress * attachVolume * createSnapshot * startVirtualMachine * deployVirtualMachine * migrateVirtualMachineWithVolume * login * logout * updateVirtualMachine Could you please provide your thoughts on this suggestion? Also, please let me know how you can help/contribute in this effort. Regards, Rajsekhar -- Daan
Improving API reference pages
{should you be adding [DISCUSS] and/or [PROPOSAL] to the subject?}
+1
Definitely required. Improvements in description/function required for both the
API call itself and associated parameters. I am willing to help with the
content.
Regards,
Somesh
-Original Message-
From: Dave Dunaway [mailto:dave.duna...@gmail.com]
Sent: Monday, August 03, 2015 9:24 AM
To: users@cloudstack.apache.org
Cc: d...@cloudstack.apache.org
Subject: Re: Improving API reference pages
I would definitely say this is needed. A few calls need to specify types
of which there is not description or they are poorly worded.
If the API doc page could have comments... that would be good too. Let the
community add examples or suggestions.
However the real deal is to document the attributes and return values for
each call. Show a basic call using curl. Describe what the call does (some
have no description). Like what most other sites with API's do :)
Here's a style guide for API documentation creation... it seems pretty
good.
http://blog.parse.com/learn/engineering/designing-great-api-docs/
HTH
dave.
On Mon, Aug 3, 2015 at 5:37 AM, Rajsekhar K rajsekharkpa...@gmail.com
wrote:
Hi, All,
This is part of our effort to improve user experience of
Cloudstack/CloudPlatform API reference pages.
Majority of the CloudStack/CloudPlatform API reference pages do not
adequately describe the usage of the parameters associated with them. Many
of these parameters contain only a single line description, which does not
really enhance the user's experience with these APIs.
CloudPlatform had received a few documentation tickets on this, with
requests to improve the description, add information on the format, and an
example on how to use the parameter. One of the tickets was on the
*migrateto *parameter in the *migrateVirtualMachineWithVolume* API
reference page. We have improved the description of the *migrateto
*parameter
as follows:
*Parameter*
*Description*
*Required*
*migrateto*
Storage to pool mapping. This parameter specifies the mapping between a
volume and a pool where you want to migrate that volume. Format of this
parameter:
migrateto[volume-index].volume=uuidmigrateto[volume-index].pool=uuidWhere,
[volume-index] indicates the index to identify the volume that you want to
migrate, volume=uuid indicates the UUID of the volume that you want to
migrate, and pool=uuid indicates the UUID of the pool where you want to
migrate the volume. Example:
migrateto[0].volume=71f43cd6-69b0-4d3b-9fbc-67f50963d60bmigrateto[0].pool=a382f181-3d2b-4413-b92d-b8931befa7e1migrateto[1].volume=88de0173-55c0-4c1c-a269-83d0279eeedfmigrateto[1].pool=95d6e97c-6766-4d67-9a30-c449c15011d1migrateto[2].volume=1b331390-59f2-4796-9993-bf11c6e76225migrateto[2].pool=41fdb564-9d3b-447d-88ed-7628f7640cbc
False
(This will be updated in the *migrateVirtualMachineWithVolume* API
reference page of CloudStack soon.)
I think I can take this as a base and improve the descriptions of the
parameters in the CloudStack/Cloudplatform API reference pages. As an
initial step, I have identified the following 20 API functions and I am
planning to improve the description of the parameters in their reference
pages:
-
*listAccounts *
-
*listCapacity *
-
*listLoadBalancerRules *
-
*listNetworks *
-
*listPublicIpAddresses *
-
*listSnapshots *
-
*listTemplates *
-
*listVirtualMachines *
-
*listVolumes *
-
*listZones *
-
*stopVirtualMachine *
-
*associateIPAddress *
-
*attachVolume *
-
*createSnapshot *
-
*startVirtualMachine *
-
*deployVirtualMachine *
-
*migrateVirtualMachineWithVolume *
-
*login *
-
*logout *
- *updateVirtualMachine*
Could you please provide your thoughts on this suggestion? Also, please let
me know how you can help/contribute in this effort.
Regards,
Rajsekhar
Improving API reference pages
Hi, All, This is part of our effort to improve user experience of Cloudstack/CloudPlatform API reference pages. Majority of the CloudStack/CloudPlatform API reference pages do not adequately describe the usage of the parameters associated with them. Many of these parameters contain only a single line description, which does not really enhance the user's experience with these APIs. CloudPlatform had received a few documentation tickets on this, with requests to improve the description, add information on the format, and an example on how to use the parameter. One of the tickets was on the *migrateto *parameter in the *migrateVirtualMachineWithVolume* API reference page. We have improved the description of the *migrateto *parameter as follows: *Parameter* *Description* *Required* *migrateto* Storage to pool mapping. This parameter specifies the mapping between a volume and a pool where you want to migrate that volume. Format of this parameter: migrateto[volume-index].volume=uuidmigrateto[volume-index].pool=uuidWhere, [volume-index] indicates the index to identify the volume that you want to migrate, volume=uuid indicates the UUID of the volume that you want to migrate, and pool=uuid indicates the UUID of the pool where you want to migrate the volume. Example: migrateto[0].volume=71f43cd6-69b0-4d3b-9fbc-67f50963d60bmigrateto[0].pool=a382f181-3d2b-4413-b92d-b8931befa7e1migrateto[1].volume=88de0173-55c0-4c1c-a269-83d0279eeedfmigrateto[1].pool=95d6e97c-6766-4d67-9a30-c449c15011d1migrateto[2].volume=1b331390-59f2-4796-9993-bf11c6e76225migrateto[2].pool=41fdb564-9d3b-447d-88ed-7628f7640cbc False (This will be updated in the *migrateVirtualMachineWithVolume* API reference page of CloudStack soon.) I think I can take this as a base and improve the descriptions of the parameters in the CloudStack/Cloudplatform API reference pages. As an initial step, I have identified the following 20 API functions and I am planning to improve the description of the parameters in their reference pages: - *listAccounts * - *listCapacity * - *listLoadBalancerRules * - *listNetworks * - *listPublicIpAddresses * - *listSnapshots * - *listTemplates * - *listVirtualMachines * - *listVolumes * - *listZones * - *stopVirtualMachine * - *associateIPAddress * - *attachVolume * - *createSnapshot * - *startVirtualMachine * - *deployVirtualMachine * - *migrateVirtualMachineWithVolume * - *login * - *logout * - *updateVirtualMachine* Could you please provide your thoughts on this suggestion? Also, please let me know how you can help/contribute in this effort. Regards, Rajsekhar
RE: Export secondary disk ova
Bimandika, It is hard to understand what you are going to achieve if exported VM runs properly. Can you re-phrase it? Vadim. -Original Message- From: Bimandika Hasanah [mailto:bimand...@live.com] Sent: Sunday, August 02, 2015 5:38 AM To: users@cloudstack.apache.org Subject: Export secondary disk ova Hi guys, I just clone root volume into data volume, and deattach data volume then download, so i get the ova file, but when i import in vmware player and virtual box it cannot run. So i try to upload again as volume and as template, the vm can run properly. What can i do to fix exported ova, so i can get a backup my vm's A bunch of thanks before Regards Bimandika Hasanah
Improving descriptions in the API reference pages
Hi, All, This is part of our effort to improve user experience of Cloudstack API reference pages. Majority of the CloudStack API reference pages do not adequately describe the usage of the parameters associated with them. Many of these parameters contain only a single line description, which does not really enhance the user's experience with these APIs. As part of this content improvement effort, I need to improve the description, add information on the format, and an example on how to use the parameter. Please find attached the improved content for the migrateto parameter in the 'migrateVirtualMachineWithVolume' API reference page as an example. I think I can take the description for the migrateto parameter as a base and improve the descriptions of the parameters in the CloudStack API reference pages. As an initial step, I have identified the following 20 API functions and I am planning to improve the description of the parameters available in their reference pages: * listAccounts * listCapacity * listLoadBalancerRules * listNetworks * listPublicIpAddresses * listSnapshots * listTemplates * listVirtualMachines * listVolumes * listZones * stopVirtualMachine * associateIPAddress * attachVolume * createSnapshot * startVirtualMachine * deployVirtualMachine * migrateVirtualMachineWithVolume * login * logout * updateVirtualMachine Could you please provide your thoughts on this suggestion? Also, please let me know how you can help/contribute in this effort. Regards, Rajsekhar migrateto.docx Description: MS-Word 2007 document
Re: Improving descriptions in the API reference pages
Whatever On Mon, Aug 3, 2015 at 3:28 AM, Rajsekhar K rajsekharkpa...@gmail.com wrote: Hi, All, This is part of our effort to improve user experience of Cloudstack API reference pages. Majority of the CloudStack API reference pages do not adequately describe the usage of the parameters associated with them. Many of these parameters contain only a single line description, which does not really enhance the user's experience with these APIs. As part of this content improvement effort, I need to improve the description, add information on the format, and an example on how to use the parameter. Please find attached the improved content for the migrateto parameter in the 'migrateVirtualMachineWithVolume' API reference page as an example. I think I can take the description for the migrateto parameter as a base and improve the descriptions of the parameters in the CloudStack API reference pages. As an initial step, I have identified the following 20 API functions and I am planning to improve the description of the parameters available in their reference pages: * listAccounts * listCapacity * listLoadBalancerRules * listNetworks * listPublicIpAddresses * listSnapshots * listTemplates * listVirtualMachines * listVolumes * listZones * stopVirtualMachine * associateIPAddress * attachVolume * createSnapshot * startVirtualMachine * deployVirtualMachine * migrateVirtualMachineWithVolume * login * logout * updateVirtualMachine Could you please provide your thoughts on this suggestion? Also, please let me know how you can help/contribute in this effort. Regards, Rajsekhar
Re: Export secondary disk ova
Hi Bimandika, Can you also let us know what the error message from VMware player / Virtualbox is? Regards, Dag Sonstebo Cloud Architect http://cloudstackcollab.org S: +44 20 3603 0540 | M: +44 7753958173 | dag.sonst...@shapeblue.com | http://www.shapeblue.com | Twitter:@ShapeBlue https://twitter.com/#!/shapeblue On 03/08/2015 06:58, Vadim Kimlaychuk vadim.kimlayc...@elion.ee wrote: Bimandika, It is hard to understand what you are going to achieve if exported VM runs properly. Can you re-phrase it? Vadim. -Original Message- From: Bimandika Hasanah [mailto:bimand...@live.com] Sent: Sunday, August 02, 2015 5:38 AM To: users@cloudstack.apache.org Subject: Export secondary disk ova Hi guys, I just clone root volume into data volume, and deattach data volume then download, so i get the ova file, but when i import in vmware player and virtual box it cannot run. So i try to upload again as volume and as template, the vm can run properly. What can i do to fix exported ova, so i can get a backup my vm's A bunch of thanks before Regards Bimandika Hasanah Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: Improving descriptions in the API reference pages
Hi Nick, If that is indeed your name, and not an alias. This is not the first time you have answered with short, at times also provocative, unnecessary messages. I, and probably more, would appreciate if you held these kind of messages to yourself, instead of polluting this list with garbage. -- Erik On Mon, Aug 3, 2015 at 12:57 PM, Nick Brody nickbrody2...@gmail.com wrote: Whatever On Mon, Aug 3, 2015 at 3:28 AM, Rajsekhar K rajsekharkpa...@gmail.com wrote: Hi, All, This is part of our effort to improve user experience of Cloudstack API reference pages. Majority of the CloudStack API reference pages do not adequately describe the usage of the parameters associated with them. Many of these parameters contain only a single line description, which does not really enhance the user's experience with these APIs. As part of this content improvement effort, I need to improve the description, add information on the format, and an example on how to use the parameter. Please find attached the improved content for the migrateto parameter in the 'migrateVirtualMachineWithVolume' API reference page as an example. I think I can take the description for the migrateto parameter as a base and improve the descriptions of the parameters in the CloudStack API reference pages. As an initial step, I have identified the following 20 API functions and I am planning to improve the description of the parameters available in their reference pages: * listAccounts * listCapacity * listLoadBalancerRules * listNetworks * listPublicIpAddresses * listSnapshots * listTemplates * listVirtualMachines * listVolumes * listZones * stopVirtualMachine * associateIPAddress * attachVolume * createSnapshot * startVirtualMachine * deployVirtualMachine * migrateVirtualMachineWithVolume * login * logout * updateVirtualMachine Could you please provide your thoughts on this suggestion? Also, please let me know how you can help/contribute in this effort. Regards, Rajsekhar
Re: Improving descriptions in the API reference pages
I don't think there is a guy named Nick Brody actually showing his disinterest here. @nick if you are there this is a turing test. You exist? On Mon, Aug 3, 2015 at 12:57 PM, Nick Brody nickbrody2...@gmail.com wrote: Whatever On Mon, Aug 3, 2015 at 3:28 AM, Rajsekhar K rajsekharkpa...@gmail.com wrote: Hi, All, This is part of our effort to improve user experience of Cloudstack API reference pages. Majority of the CloudStack API reference pages do not adequately describe the usage of the parameters associated with them. Many of these parameters contain only a single line description, which does not really enhance the user's experience with these APIs. As part of this content improvement effort, I need to improve the description, add information on the format, and an example on how to use the parameter. Please find attached the improved content for the migrateto parameter in the 'migrateVirtualMachineWithVolume' API reference page as an example. I think I can take the description for the migrateto parameter as a base and improve the descriptions of the parameters in the CloudStack API reference pages. As an initial step, I have identified the following 20 API functions and I am planning to improve the description of the parameters available in their reference pages: * listAccounts * listCapacity * listLoadBalancerRules * listNetworks * listPublicIpAddresses * listSnapshots * listTemplates * listVirtualMachines * listVolumes * listZones * stopVirtualMachine * associateIPAddress * attachVolume * createSnapshot * startVirtualMachine * deployVirtualMachine * migrateVirtualMachineWithVolume * login * logout * updateVirtualMachine Could you please provide your thoughts on this suggestion? Also, please let me know how you can help/contribute in this effort. Regards, Rajsekhar -- Daan
Re: Cloudstack support
On Thu, Jul 23, 2015 at 7:37 PM, Orlando Sánchez tecnologia.8...@outlook.com wrote: Hello Everybody, I am sorry for the off topic but I am not sure where could I get information about the following. We have a cloudstack infrastructure in our company running 4.1, unfortunately our senior engineer left and we need external support to help us with level 3 support. Is there any company who could provide us this service? Again I am sorry for the off topic, I hope anybody could help us. We have support agreements with at least two rather big CloudStack players, and I just want to say that small companies does not have to be a bad thing. Things to consider: - Location of support: Most companies can provide 24/7 support availability, but you should prefer someone that has native work hours at approximately the same time as you. Using someone that has working hours when you normally sleep means you have to rely on their night shift when you're usually working. - Size: Large companies often have multiple tiers of support personnel, which means you might end up waiting for escalations to get your case to someone that knows more. This easily becomes frustrating. You'll also want to make sure that the company is not heavily dependent on a few critical persons - that can easily become a problem in case of sickness, traveling, change of jobs etc. - Community involvement: ACS is built by a lot of persons/companies, and your support partner might not be able to solve it all by themselves. You want to use someone who is actively involved with the community to ensure they can pull the right strings if they need assistance. Ask for names by the sales rep. and check the git log/mailling list/forums etc. to verify their involvement. -- Erik
Re: Improving API reference pages
I would definitely say this is needed. A few calls need to specify types of which there is not description or they are poorly worded. If the API doc page could have comments... that would be good too. Let the community add examples or suggestions. However the real deal is to document the attributes and return values for each call. Show a basic call using curl. Describe what the call does (some have no description). Like what most other sites with API's do :) Here's a style guide for API documentation creation... it seems pretty good. http://blog.parse.com/learn/engineering/designing-great-api-docs/ HTH dave. On Mon, Aug 3, 2015 at 5:37 AM, Rajsekhar K rajsekharkpa...@gmail.com wrote: Hi, All, This is part of our effort to improve user experience of Cloudstack/CloudPlatform API reference pages. Majority of the CloudStack/CloudPlatform API reference pages do not adequately describe the usage of the parameters associated with them. Many of these parameters contain only a single line description, which does not really enhance the user's experience with these APIs. CloudPlatform had received a few documentation tickets on this, with requests to improve the description, add information on the format, and an example on how to use the parameter. One of the tickets was on the *migrateto *parameter in the *migrateVirtualMachineWithVolume* API reference page. We have improved the description of the *migrateto *parameter as follows: *Parameter* *Description* *Required* *migrateto* Storage to pool mapping. This parameter specifies the mapping between a volume and a pool where you want to migrate that volume. Format of this parameter: migrateto[volume-index].volume=uuidmigrateto[volume-index].pool=uuidWhere, [volume-index] indicates the index to identify the volume that you want to migrate, volume=uuid indicates the UUID of the volume that you want to migrate, and pool=uuid indicates the UUID of the pool where you want to migrate the volume. Example: migrateto[0].volume=71f43cd6-69b0-4d3b-9fbc-67f50963d60bmigrateto[0].pool=a382f181-3d2b-4413-b92d-b8931befa7e1migrateto[1].volume=88de0173-55c0-4c1c-a269-83d0279eeedfmigrateto[1].pool=95d6e97c-6766-4d67-9a30-c449c15011d1migrateto[2].volume=1b331390-59f2-4796-9993-bf11c6e76225migrateto[2].pool=41fdb564-9d3b-447d-88ed-7628f7640cbc False (This will be updated in the *migrateVirtualMachineWithVolume* API reference page of CloudStack soon.) I think I can take this as a base and improve the descriptions of the parameters in the CloudStack/Cloudplatform API reference pages. As an initial step, I have identified the following 20 API functions and I am planning to improve the description of the parameters in their reference pages: - *listAccounts * - *listCapacity * - *listLoadBalancerRules * - *listNetworks * - *listPublicIpAddresses * - *listSnapshots * - *listTemplates * - *listVirtualMachines * - *listVolumes * - *listZones * - *stopVirtualMachine * - *associateIPAddress * - *attachVolume * - *createSnapshot * - *startVirtualMachine * - *deployVirtualMachine * - *migrateVirtualMachineWithVolume * - *login * - *logout * - *updateVirtualMachine* Could you please provide your thoughts on this suggestion? Also, please let me know how you can help/contribute in this effort. Regards, Rajsekhar
RE: Management server down
Ok so I am back in the office and able to log into the servers. The management server UI is down with a tomcat 404 error the catalina.out has not rotated since 8.1 and has grown to 353MB while management-server.log is still from 8.1 and is 9MB in size. So now that I get my hands on my logs files. 2015-08-01 12:30:04,925 ERROR [c.c.u.d.Merovingian2] (main:null) Unable to get a new db connection com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Could not create connection to database server. Attempted reconnect 3 times. Giving up. Crap crap crap. I am able to ping my server farm but for some reason my management network cannot dig lookup from my management servers to the db servers. So I quickly fixed the nsservers and since I was able to ping but not hit named. Now my UI is back working. Jeremy -Original Message- From: Nick Brody [mailto:nickbrody2...@gmail.com] Sent: Sunday, August 2, 2015 2:51 AM To: users@cloudstack.apache.org Subject: Re: Management server down Superphones On Sat, Aug 1, 2015 at 11:47 AM, Ahmad Emneina aemne...@gmail.com wrote: Jeremy, can you paste logs to a service like pastebin... Typically the UI fails to load when the management server doesn't start properly... Management server logs and/Catalina.out should point to the problem. Ahmad E On Aug 1, 2015, at 11:34 AM, Milamber milam...@apache.org wrote: The screenshot of latest lines of catalina.out don't pass the mailing list (probably dropped) What says the cloudstack-management.log file when your restart the service ? (your CS version?) On 01/08/2015 19:06, Jeremy Peterson wrote: So out server farm is hosted in our corporate ESX environment. Our ESX hosts are over provisioned and we are waiting to get some UCS blades to bring our utilization down. But one of our hosts shutdown last night and HA was unable to keep all VM’s running. We fixed the issue our ESX host is back online but our cloudstack farm is unhappy. My DB servers are up and functional. My Management servers are online and can communicated to all servers My LB’s are good HA Proxy is working. My DNS servers are up and can resolve all servers and all servers can resolve to DNS propery. My hosts are online XenServer 6.5 SP1 and my vm’s are up. But when I restart cloudstack-management I end up with a tomcat 404 error. *HTTP Status 404 -* --- - *type* Status report *message* *description*_The requested resource () is not available._ --- - *Apache Tomcat/6.0.24* I am remote at this time and that is the last couple lines of catalina.out Anyone have any ideas? *Jeremy Peterson *
