openstack-aps-package-dev team mailing list archive

[Dmitry Savenkov <dsavenkov@xxxxxxxxxxxx>]

Hi Evgeniya:

I agree that this should probably be moved out of the scope.

However, if it's the case, we need to agree on a replacement of this
(quotas are going to be specified in the same screen?)

Also, regarding the user stories: *the ones that are above are too generic
and epic. What we will need to do is review the user stories that I have
requested Jonathan/guys should create and decide whether they all naturally
belong to this release, which are not described correctly, etc. To my mind,
it's very likely to be the case that we are not on the same page/view
everything differently, which can be concluded based on emails from our
threads.*

Thanks for your feedback.

Kind Regards,
Dmitry.

On Sat, Sep 13, 2014 at 2:25 AM, Evgeniya Shumakher <eshumakher@xxxxxxxxxxxx
> wrote:

> 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>
>