cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ilya <ilya.mailing.li...@gmail.com>
Subject Re: Opportunity to contribute in Apache CloudStack
Date Sat, 09 Jul 2016 06:02:42 GMT
I agree that usage UI would be beneficial.

As other folks mentioned on this thread, cloudstack collects the usage
metrics for each VM via cloud-usage service stored on cloud_usage
database. We've been lacking this for some time now.

One other nice feature that would help apache cloudstack project alot -
is "cloudstack manager".

Conceptually - this means you have many cloudstack management servers
across the globe in different data centers, but there is nothing right
now that ties them all together.

As the result - each cloudstack environment is managed as its own
entity. Most companies then write their own "managers" or have scripts
that keep cloudstacks in-sync and healthy. If you have large
environments with thousands of hypervisors, many users and countless VMs
- it can go wild pretty quickly.

What does it mean (for new comers), cloudstack has many constructs:
Global Settings
Service, Disk Offerings, Templates
Zone Settings, Cluster Settings
Storage Settings
Healths of hypervisors, system and router vms
Users, accounts and domains
Virtual Machines
...and more

All of the above - could be managed via CloudStack API. However, its
painful to keep all environments consistent.  Keeping your environments
consistent and having a single view - great simplifies the management of
dispersed cloudstack environments.

Either way - both are great projects - i can certainly help with use
cases and requirements for "cloudstack manager".

I'm pretty certain other folks in the community would help with "usage"
project.

Let us know what you would like to pursue.

Again, thank you for your participation

Regards,
ilya


On 7/8/16 3:30 AM, Erik Weber wrote:
> Pricing is hard to do, since there are so many different ways an
> organization might be doing their sales, so I would not focus on that for
> the first release, but rather do it later.
> Make a minimum viable product/solution and take it from there.
> 

Mime
View raw message