Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update README.md #3

Merged
merged 1 commit into from
Apr 21, 2015
Merged

Update README.md #3

merged 1 commit into from
Apr 21, 2015

Conversation

jamesrcounts
Copy link

cd ./che should be off the current dir, not the root. Dot was missing.

`cd ./che` should be off the current dir, not the root.  Dot was missing.
TylerJewell pushed a commit that referenced this pull request Apr 21, 2015
@TylerJewell TylerJewell merged commit 03b15b3 into eclipse-che:master Apr 21, 2015
@jamesrcounts jamesrcounts deleted the patch-1 branch April 21, 2015 00:34
benoitf added a commit that referenced this pull request May 27, 2016
…ove InstanceKey

#1 new docker recipe type

currently we have type:"dockerfile", location: "http://path-to-recipe"

now we could provide
type:"dockerfile", content: "FROM codenvy/foo\nENV FLORENT=TRUE\"

and
type:"image", location or content: "codenvy/foo"

#2 InstanceKey
Up to now, InstanceKey was used to perform snapshot recovery.
But machine source is a way to provide this information.
So remove InstanceKey and replace it by MachineSource (and DockerMachineSource instead of DockerInstanceKey)

InstanceProvider:
void removeInstanceSnapshot(InstanceKey instanceKey)
--> void removeInstanceSnapshot(MachineSource machineSource)

Instance:
InstanceKey saveToSnapshot(String owner)
--> MachineSource saveToSnapshot(String owner)

#3 InstanceProvider model
To avoid also that MachineManager "knows" the inner type, the recipe handling is moved to the instance provider implementation
And as the snapshot handling is with MachineSource (included in MachineConfig included in Machine), no need to give extra InstanceKey parameter

Replace two previous methods

Instance createInstance(Recipe recipe,
                            Machine machine,
                            LineConsumer creationLogsOutput)

 Instance createInstance(InstanceKey instanceKey,
                            Machine machine,
                            LineConsumer creationLogsOutput) throws NotFoundException, InvalidInstanceSnapshotException, MachineException;

by only one:
   createInstance(Machine machine,
                            LineConsumer creationLogsOutput)

Change-Id: Ia7ea97bc1a44059b4892f5db387f54f2e1709fa3
Signed-off-by: Florent BENOIT <[email protected]>
benoitf added a commit that referenced this pull request May 29, 2016
…ove InstanceKey

#1 new docker recipe type

currently we have type:"dockerfile", location: "http://path-to-recipe"

now we could provide
type:"dockerfile", content: "FROM codenvy/foo\nENV FLORENT=TRUE\"

and
type:"image", location or content: "codenvy/foo"

#2 InstanceKey
Up to now, InstanceKey was used to perform snapshot recovery.
But machine source is a way to provide this information.
So remove InstanceKey and replace it by MachineSource (and DockerMachineSource instead of DockerInstanceKey)

InstanceProvider:
void removeInstanceSnapshot(InstanceKey instanceKey)
--> void removeInstanceSnapshot(MachineSource machineSource)

Instance:
InstanceKey saveToSnapshot(String owner)
--> MachineSource saveToSnapshot(String owner)

#3 InstanceProvider model
To avoid also that MachineManager "knows" the inner type, the recipe handling is moved to the instance provider implementation
And as the snapshot handling is with MachineSource (included in MachineConfig included in Machine), no need to give extra InstanceKey parameter

Replace two previous methods

Instance createInstance(Recipe recipe,
                            Machine machine,
                            LineConsumer creationLogsOutput)

 Instance createInstance(InstanceKey instanceKey,
                            Machine machine,
                            LineConsumer creationLogsOutput) throws NotFoundException, InvalidInstanceSnapshotException, MachineException;

by only one:
   createInstance(Machine machine,
                            LineConsumer creationLogsOutput)

Change-Id: Ia7ea97bc1a44059b4892f5db387f54f2e1709fa3
Signed-off-by: Florent BENOIT <[email protected]>
benoitf added a commit that referenced this pull request May 30, 2016
…ove InstanceKey

#1 new docker recipe type

currently we have type:"dockerfile", location: "http://path-to-recipe"

now we could provide
type:"dockerfile", content: "FROM codenvy/foo\nENV FLORENT=TRUE\"

and
type:"image", location or content: "codenvy/foo"

#2 InstanceKey
Up to now, InstanceKey was used to perform snapshot recovery.
But machine source is a way to provide this information.
So remove InstanceKey and replace it by MachineSource (and DockerMachineSource instead of DockerInstanceKey)

InstanceProvider:
void removeInstanceSnapshot(InstanceKey instanceKey)
--> void removeInstanceSnapshot(MachineSource machineSource)

Instance:
InstanceKey saveToSnapshot(String owner)
--> MachineSource saveToSnapshot(String owner)

#3 InstanceProvider model
To avoid also that MachineManager "knows" the inner type, the recipe handling is moved to the instance provider implementation
And as the snapshot handling is with MachineSource (included in MachineConfig included in Machine), no need to give extra InstanceKey parameter

Replace two previous methods

Instance createInstance(Recipe recipe,
                            Machine machine,
                            LineConsumer creationLogsOutput)

 Instance createInstance(InstanceKey instanceKey,
                            Machine machine,
                            LineConsumer creationLogsOutput) throws NotFoundException, InvalidInstanceSnapshotException, MachineException;

by only one:
   createInstance(Machine machine,
                            LineConsumer creationLogsOutput)

Change-Id: Ia7ea97bc1a44059b4892f5db387f54f2e1709fa3
Signed-off-by: Florent BENOIT <[email protected]>
benoitf added a commit that referenced this pull request May 30, 2016
…ove InstanceKey

#1 new docker recipe type

currently we have type:"dockerfile", location: "http://path-to-recipe"

now we could provide
type:"dockerfile", content: "FROM codenvy/foo\nENV FLORENT=TRUE\"

and
type:"image", location or content: "codenvy/foo"

#2 InstanceKey
Up to now, InstanceKey was used to perform snapshot recovery.
But machine source is a way to provide this information.
So remove InstanceKey and replace it by MachineSource (and DockerMachineSource instead of DockerInstanceKey)

InstanceProvider:
void removeInstanceSnapshot(InstanceKey instanceKey)
--> void removeInstanceSnapshot(MachineSource machineSource)

Instance:
InstanceKey saveToSnapshot(String owner)
--> MachineSource saveToSnapshot(String owner)

#3 InstanceProvider model
To avoid also that MachineManager "knows" the inner type, the recipe handling is moved to the instance provider implementation
And as the snapshot handling is with MachineSource (included in MachineConfig included in Machine), no need to give extra InstanceKey parameter

Replace two previous methods

Instance createInstance(Recipe recipe,
                            Machine machine,
                            LineConsumer creationLogsOutput)

 Instance createInstance(InstanceKey instanceKey,
                            Machine machine,
                            LineConsumer creationLogsOutput) throws NotFoundException, InvalidInstanceSnapshotException, MachineException;

by only one:
   createInstance(Machine machine,
                            LineConsumer creationLogsOutput)

Change-Id: Ia7ea97bc1a44059b4892f5db387f54f2e1709fa3
Signed-off-by: Florent BENOIT <[email protected]>
benoitf added a commit that referenced this pull request May 30, 2016
…ove InstanceKey

#1 new docker recipe type

currently we have type:"dockerfile", location: "http://path-to-recipe"

now we could provide
type:"dockerfile", content: "FROM codenvy/foo\nENV FLORENT=TRUE\"

and
type:"image", location or content: "codenvy/foo"

#2 InstanceKey
Up to now, InstanceKey was used to perform snapshot recovery.
But machine source is a way to provide this information.
So remove InstanceKey and replace it by MachineSource (and DockerMachineSource instead of DockerInstanceKey)

InstanceProvider:
void removeInstanceSnapshot(InstanceKey instanceKey)
--> void removeInstanceSnapshot(MachineSource machineSource)

Instance:
InstanceKey saveToSnapshot(String owner)
--> MachineSource saveToSnapshot(String owner)

#3 InstanceProvider model
To avoid also that MachineManager "knows" the inner type, the recipe handling is moved to the instance provider implementation
And as the snapshot handling is with MachineSource (included in MachineConfig included in Machine), no need to give extra InstanceKey parameter

Replace two previous methods

Instance createInstance(Recipe recipe,
                            Machine machine,
                            LineConsumer creationLogsOutput)

 Instance createInstance(InstanceKey instanceKey,
                            Machine machine,
                            LineConsumer creationLogsOutput) throws NotFoundException, InvalidInstanceSnapshotException, MachineException;

by only one:
   createInstance(Machine machine,
                            LineConsumer creationLogsOutput)

Change-Id: Ia7ea97bc1a44059b4892f5db387f54f2e1709fa3
Signed-off-by: Florent BENOIT <[email protected]>
@slemeur slemeur mentioned this pull request Oct 3, 2016
17 tasks
@TylerJewell TylerJewell mentioned this pull request Dec 19, 2016
mkuznyetsov referenced this pull request in mkuznyetsov/che Aug 14, 2017
Get rid of default test user in selenium tests
Katka92 referenced this pull request in Katka92/che Jun 27, 2018
Small fixes to templates, build script and deployment script
rhopp added a commit to rhopp/che that referenced this pull request Nov 26, 2020
@nickboldt nickboldt mentioned this pull request Apr 7, 2021
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants