Open Stack

> On Feb 18, 2014, at 4:41 PM, "Angus Salkeld" <angus.salkeld at rackspace.com> wrote:
> 
>> On 18/02/14 14:19 +0000, Shaunak Kashyap wrote:
>> Thanks Angus and Devdatta. I think I understand.
>> 
>> Angus -- what you said seems to mirror the Heroku CLI usage: a) User runs "app/plan create" (to create the remote repo), then b) user runs "git push ..." (which pushes the code to the remote repo and creates 1 assembly, resulting in a running application). If this is the intended flow for the user, it makes sense to me.
> 
> Just to be clear, I am not totally sure we are going to glue git repo
> generation to create plan (it *could* be part of create assembly).

Yes, it's possible to hang repo creation on create assembly, but you only need that when you first set up the app. After that point, the repo exists, and you can just make updates to the plan (when making a new release, for example), and create new assemblies from it.

If the user calls "assembly create" using a plan file that has a requirement like "git-init", that requirement could be fulfilled by a matching "git-init" service. If the repo does not exist yet, the matching service can create one. Otherwise, it can return taking no action. This feature is not necessary if "plan create" has the equivalent, but both wold work exactly the same way. This might be convenient for users who prefer not to bother with creating any plan resources. This cuts one step out of the workflow, but it requires you to keep track of your plan file forever and keep passing it in by value every time you create an assembly, rather than just at initial app creation time. Subsequent assembly creations would be faster when using a reference to a plan that Solum already has, rather than passing it in by value, or causing Solum to download it from a code repo each time.

>> One follow up question: under what circumstances will the user need to explicitly run "assembly create"? Would it be used exclusively for adding more assemblies to an already running app?
> 
> If you are not using the git-push mechanism, but the git-pull.
> Here you have your own repo (say on github) and there is not
> a git-repo-generation phase.

See my remarks above on this. You might want a plan even in a git-pull scenario if you expect to create multiple matching assemblies.

Adrian

> -Angus
> 
>> 
>> Thanks,
>> 
>> Shaunak
>> 
>> ________________________________________
>> From: Angus Salkeld [angus.salkeld at rackspace.com]
>> Sent: Monday, February 17, 2014 5:54 PM
>> To: openstack-dev at lists.openstack.org
>> Subject: Re: [openstack-dev] [solum] Question about solum-minimal-cli BP
>> 
>>> On 17/02/14 21:47 +0000, Shaunak Kashyap wrote:
>>> Hey folks,
>>> 
>>> I was reading through https://wiki.openstack.org/wiki/Solum/FeatureBlueprints/CLI-minimal-implementation and have a question.
>>> 
>>> If I’m understanding “app create” and “assembly create” correctly, the user will have to run “app create” first, followed by “assembly create” to have a running application. Is this correct? If so, what is the reason for “app create” not automatically creating one assembly as well?
>> 
>> On that page it seems that "app create" is the same as "plan create".
>> 
>> The only reason I can see for seperating the plan from the assembly is
>> when you have "git-push".
>> Then you need to have something create the git repo for you.
>> 
>> 1 plan create (with a reference to a git-push requirement) would create
>>  the remote git repo for you.
>> 2 you clone and populate the repo with your app code
>> 3 you push, and that causes the assembly create/update.
>> 
>> Adrian might want to correct my here tho'
>> 
>> -Angus
>> 
>>> 
>>> Thanks,
>>> Shaunak
>> 
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev