openstack-aps-package-dev team mailing list archive

[Dmitry Savenkov <dsavenkov@xxxxxxxxxxxx>]

Folks,

In this case I believe one more user story needs to be created covering the
creation of heat templates in the resource model (non-visual US, which is
acceptable).

Also, now I don't understand what we are going to replace Heat Templates
with. The screen apparently needs to be changed, and if you mean it needs
to be gotten rid of, where are we going to enable the user to specify
quotas (RAM, disk, cores, etc.)?

Thanks.

Kind Regards,
Dmitry.

On Sat, Sep 13, 2014 at 2:38 AM, Andre Moruga <amoruga@xxxxxxxxxxxxx> wrote:

>  Jenya, I don’t think Heat Orchestration Template and tenant quotas are
> confused. However you are right heat templates are not in scope on MVP.
>
> However as I said, we wanted to design resource model from very beginning
> to support them, because very likely very first customer will ask for it
> (as it would allow them to sell ready-to-go appliances rather than tenant
> accounts with nothing inside)
>
>
>
> So the suggestions was: implement heat templates as a part of resource
> model (as a prototype effort) but drop it from UI and usecases
>
>
>
> *From:* Evgeniya Shumakher [mailto:eshumakher@xxxxxxxxxxxx]
> *Sent:* Friday, September 12, 2014 4:26 PM
> *To:* Dmitry Savenkov
> *Cc:* Andre Moruga; openstack-aps-package-dev@xxxxxxxxxxxxxxxxxxx; Juan
> Victor Izquierdo
> *Subject:* Re: APS & OpenStack - Replies To The Questions (last Tuesday's
> meeting)
>
>
>
> Folks,
>
> I think there is a sort of confusion here with Heat.
>
>
>
> First of all, Heat is an orchestration component in OpenStack:
> https://wiki.openstack.org/wiki/Heat
>
>
>
> And there is such a thing as Heat Template, actually it's Heat
> Orchestration Template (HOT), and here is the link it its description:
>
> http://docs.openstack.org/developer/heat/template_guide/hot_guide.html
>
>
>
> To be able to use HOT, Heat OpenStack component must be installed. In fact
> it is *not installed* on the OpenStack sandbox we provided.
>
> It's not an issue, in case it's necessary Heat can be deployed there or
> even on a remote location:
> http://docs.openstack.org/developer/heat/getting_started/standalone.html
>
>
>
> My concern is the following.
>
> We do we actually discuss Heat templates? It's *not in the scope* of the
> MVP.
>
>
>
> We have the following user stories to cover:
>
>
>
> SPUS-10
>
> Create multiple service plan with different quotas
>
> Any quota supported in OpenStack can be supported as PA resource quota
>
> All the resources available in OpenStack can be purchased and configured
> in PA
>
> In scope to create a provider guide to configure the needed SP.
>
>
>
> SPUS-30
>
> Define price for CPU, storage, RAM, public IP, external traffic (inbound,
> outbound, total), cost of Operating System
>
> Can be defined for for monthly subscription (monthly price) or hourly PAYG
> subscription
>
> Service provider will be able to configure the price for the individual
> resources. Resources can be billed monthly or hourly
>
> In scope to create providers guide explanation on how to define prices in
> PBA
>
>
>
> In my opinion quotas mentioned above should map on *tenant/project quotas*:
> http://docs.openstack.org/user-guide-admin/content/cli_set_quotas.html
>
> Please remember how simple the workflow we are working on should be: *specify
> tenant quotas-> sell an access to a tenant with specific quotas->give a
> link to get access to the tenant->charge on a flat basis*.
>
> Practically the same for PAYG
>
>
>
> More info about tenants/projects:
> http://docs.openstack.org/openstack-ops/content/projects_users.html
>
>
>
> There are also *flavors*, which specify quotas for a single VM:
> http://docs.openstack.org/user-guide-admin/content/cli_manage_flavors.html
>
> Looks like they are *out of scope* for now.
>
>
>
> HOT allows not only specify vCPU size for a VM, but to describe the
> infrastructure and applications within an OpenStack cloud.
>
> It's definitely a good idea to enable Heat, create and run * HOTs* from
> PA UI. But let's move it *out of scope* of discussion and implementation.
>
>
>
> Though we do need to design the resource model the way supports/can be
> extended to support both flavors and Heat resources.
>
>
>
>
>
> So here is my* summary/proposal:*
>
>    1. What we mean under Heat template now is just a Tenant quota.
>    2. Let's avoid usage of 'Heat' in the resource model. I propose to
>    rename it to something neutral.
>    3. Mamasu team, i expect you to get familiar with OpenStack
>    terminology. It looks like we are experiencing such issues, because you
>    didn't pay enough attention to study the OpenStack domain.
>    4. The project should be focused on the delivery of MVP. Please go to
>    the SRS and make sure are covered all USs specified there.
>
>  Let me know if there are any questions.
>
>
>
> Thanks.
>
>
>
> --
>
> Evgeniya
>
>
>
>
>
> On Fri, Sep 12, 2014 at 9:48 AM, Dmitry Savenkov <dsavenkov@xxxxxxxxxxxx>
> wrote:
>
>  Hi Andrey,
>
>
>
> Thank you for the email.
>
>
>
> One question: As I spoke with our OpenStack experts today, I was never
> faced with a notion such as Heat Template (Heat Attack), they only
> mentioned FLAVOUR. I am not personally sure heat templates exist in
> OpenStack, so will need to follow up on this. For Flavours a certain set of
> params can be retrieved.
>
>
>
> Let me know if there are any other questions.
>
>
>
> Kind Regards,
>
> Dmitry.
>
>
>
> On Fri, Sep 12, 2014 at 7:10 PM, Andre Moruga <amoruga@xxxxxxxxxxxxx>
> wrote:
>
>  Dima, thanks
>
> One question is still open: item #2 is about ability to retrieve
> parameters for heat attack (not a general template). Not sure this is the
> one was answered.
>
>
>
> Jonathan – some conclusions on the others:
>
>
>
> 1)      We do need to handle situation when image is removed in Glance
> (show it as problematic, suggest to either fix or remove)
>
> 2)      Waiting for clarification here
>
> 3)      For images: we need to display Name (retrieved from API), size
> (API), OS (provider types, mandatory), description (provider types,
> optional, not shown in grid mode but left for details)
>
>
>
> *From:* Dmitry Savenkov [mailto:dsavenkov@xxxxxxxxxxxx]
> *Sent:* Friday, September 12, 2014 8:11 AM
> *To:* Andre Moruga
> *Cc:* openstack-aps-package-dev@xxxxxxxxxxxxxxxxxxx; Juan Victor
> Izquierdo; Evgeniya Shumakher
> *Subject:* APS & OpenStack - Replies To The Questions (last Tuesday's
> meeting)
>
>
>
> Andrey:
>
> Today I was successfully able to get our OpenStack experts to reply to the
> questions that had been triggered by our recent meeting. I will list the
> questions below along with replies to them. Please mind that I didn't test
> the APIs that could retrieve some values, so it's up to *Mamasu *to do
> that and let me know the results.
>
>
> *The questions are: *
> 1) Find out if an image that is being used by a VM/server can be removed
> from OpenStack via Glance (or if there are any APIs enabling the user to do
> so).
>
> 2) Can RAM/CPU/other parameters can be retrieved in OpenStack from a
> template by means of any APIs?
>
> 3) Image: What type of information can be retrieved re an image (OS/ all
> the possible parameters) - metadata ?
>
>
> *Please see the replies below: *
> 1) it's possible to remove an image that is being referenced by any
> VM/instance via Glance/API (an image is copied to a compute node when it's
> provisioned). The folder is: instance/_base‏
>
> 2)  it's also possible to get various flavor parameters by invoking *nova
> flavor-list*‏ (http://developer.openstack.org/api-ref-compute-v2.html).
>
> */v2/{tenant_id}/flavors/detail* needs to be called. *minRam *and *minDisk
> *parameters can be specified. However, I am not sure why the 'min' prefix
> is in place.. Will try to clarify this with our OpenStack experts.
>
> * vcpu (number of cores), ram, disk can be retrieved (response json)*
>
> 3) There is an image API enabling the retrieval of an image parameters. A
> link to it is here: http://developer.openstack.org/api-ref-image-v2.html.
> However, neither OS nor the number of instances are in the list (only the *image
> link prop* is in the main list).
>
> The number of instances using an image can be retrieved by invoking the
> following: *nova list --all-tenants --image <image_UUID>*. The API
> reference is here:http://developer.openstack.org/api-ref-compute-v2.html.
>
> In order to retrieve the OS, please take a look at *xsd:dict Properties*
> key-value tags. It should be contained there (according to our specialist).
>
>
> *A question for Andrey: Andrey, do you have access to our Jira? If so, I
> would be able to share our tickets containing questions with you. It would
> be more convenient. *
> Please let me know if there are any questions in this regards.
>
> Thanks.
>
> Kind Regards,
> Dmitry.
>
>
>
>
>
>
>
>
>
> --
>
> --
>
> Regards,
> Evgeniya
>
> Mirantis, Inc
>
>
>
> Mob.phone: +7 (968) 760-98-42
> Email: eshumakher@xxxxxxxxxxxx
> Skype: eshumakher
>
>
>
> [image: Register today: OpenStack Silicon Valley | 16 September 2014]
> <http://www.openstacksv.com>
>