redhat-et / copilot-ops

copilot-ops is a CLI tool that boosts up any DevOps repo to a ninja level of Artificially Intelligent Ops Repo
Apache License 2.0
34 stars 13 forks source link

Specifying `edit-only` vs. `generate` mode #17

Closed RobotSail closed 2 years ago

RobotSail commented 2 years ago

Related to #16, the Codex /edits endpoint will only edit files in-place based on the provided input, but it does not provide new additions in terms of new files.

For example, the following prompt + input works as expected:

files:

# @kustomization
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
    - namespace.yaml
    - resourcequota.yaml
components:
    - ../../../../components/project-admin-rolebindings/octo-training-model
    - ../../../../components/limitranges/default
namespace: training-model

input:

@kustomization needs to add `globalresources.yaml` to its `.resources` field.

Produces the output:

# @kustomization
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
    - namespace.yaml
    - resourcequota.yaml
    - globalresources.yaml
components:
    - ../../../../components/project-admin-rolebindings/octo-training-model
    - ../../../../components/limitranges/default
namespace: training-model

However, specifying the following only produces changes to @kustomization and doesn't generate the newly requested resource:

files:

# @kustomization
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
    - namespace.yaml
    - resourcequota.yaml
components:
    - ../../../../components/project-admin-rolebindings/octo-training-model
    - ../../../../components/limitranges/default
namespace: training-model

input

@kustomization needs to add `globalresources.yaml` to its `.resources` field.

We also need to create a new ConfigMap tagged `@configmap` containing a username and password for the model to pull from and use as authentication for the dataset

Produces:

# @kustomization
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
    - namespace.yaml
    - resourcequota.yaml
    - globalresources.yaml
components:
    - ../../../../components/project-admin-rolebindings/octo-training-model
    - ../../../../components/limitranges/default
namespace: training-model

Parameters used in completion:

{
  "temperature": 0.16,
  "top_p": 1
}
RobotSail commented 2 years ago

At the moment, there are three (possibly four) scenarios that could happen:

  1. User only wants to edit the existing files, giving us edit mode, which would use the /edits endpoint
  2. User wants to generate a new file on top of the existing ones specified, so a generate mode which hits the /completions endpoint
  3. User wants to make edits and generate a new file, edit + generate mode. This could be accomplished by chaining together edit and generate, but in which order?
  4. User wants to generate a new file and then make edits. This scenario makes sense when a new file is generated and the existing files should be updated to include the new one in their values.
RobotSail commented 2 years ago

@guymguym What do you think of the above?

guymguym commented 2 years ago

@RobotSail I think we already saw that the edit API is capable of generating new files too. Is there anything to be done here still or should we close?

RobotSail commented 2 years ago

@guymguym I was thinking about that during our meeting with Ryan yesterday. From what I've seen so far, edits still struggles with generating without specific wording, whereas completions does it by default. We can probably create a new command generate or add a --generate option to patch which assumes that the user wants to generate an entirely new file. The completions endpoint would work much better with this, and if we're using filesets then we would already have an idea of where the generated file should be saved to.