✨ add payload for manifestwork #269
Conversation
|
/assign @qiujian16 |
|
/assign @morvencao |
| } | ||
|
|
||
| // SingleManifest represents the data in a cloudevent, it contains a single manifest. | ||
| type SingleManifest struct { |
There was a problem hiding this comment.
nit: do we need 'single', 'Manifest' is more simpler and straightforward?
There was a problem hiding this comment.
Use Manifest as the struct name
client/cloudevents/types/types.go
Outdated
| @@ -19,6 +19,14 @@ const ( | |||
| SourceAll = "" | |||
| ) | |||
|
|
|||
| const ( | |||
| // CloudEventsDataTypeAnnotationKey is the key of the cloudevents data type annotation. | |||
| CloudEventsDataTypeAnnotationKey = "cloudevents.open-cluster-management.io/datatype" | |||
There was a problem hiding this comment.
this will be used by work-agent to distinguish a manifestwork's event data type, move to work package
skeeey
force-pushed
the
cloudevents-mw
branch
2 times, most recently
from
7351025 to
379ee7d
Compare
| Status *workv1.ManifestCondition `json:"status,omitempty"` | ||
| } | ||
|
|
||
| type ManifestConfigOption struct { |
There was a problem hiding this comment.
why not use ManifestConfigOption in work api? because of the resourcemeta field?
There was a problem hiding this comment.
yes, it is, for a single manifest, I think we alreay have a certain type resource, so we may not set the resourcemeta outside
| ) | ||
|
|
||
| // ManifestWorkLister list the ManifestWorks from a ManifestWorkInformer's local cache. | ||
| type ManifestWorkLister struct { |
There was a problem hiding this comment.
how does this lister get initiated?
There was a problem hiding this comment.
when we build the work clients for cloud events, we use inform store to initiate it
There was a problem hiding this comment.
if it is from informer, why we not use lister directly but using cache.store?
There was a problem hiding this comment.
yeah, a lister can be used here, I will use lister instead of store
| return func(action types.ResourceAction, work *workv1.ManifestWork) error { | ||
| switch action { | ||
| case types.Added: | ||
| _, err := workClient.Create(ctx, work, metav1.CreateOptions{}) |
There was a problem hiding this comment.
this is not clear to me, why the resource handler finally creates a manifestwork using a client? I thought you are going to put it in the cache.Store.
There was a problem hiding this comment.
yes, it will be put in the store finally, we will have a new client, it implements the ManifestWorkInterface, the client will put the manifestwork to the sore, the logic will be same with here, so I used the client to handle this
There was a problem hiding this comment.
it is confusing I think, if it is a certain type client, we should use that as the input instead of the interface.
There was a problem hiding this comment.
hrm... I do not introduce the new client in this pr yet, I will add the implementation, and use a certain type client
will add it |
skeeey
force-pushed
the
cloudevents-mw
branch
2 times, most recently
from
ebf6c0c to
4558fdd
Compare
| klog.V(4).Infof("deleting manifestwork %s", name) | ||
| work, err := c.lister.Get(name) | ||
| if err != nil { | ||
| return err |
| return err | ||
| } | ||
|
|
||
| c.watcher.Receive(watch.Event{Type: watch.Modified, Object: work}) |
There was a problem hiding this comment.
what is the intension of this? and I do not think agent should have the permission to delete?
There was a problem hiding this comment.
good catch, we don't need the delete function for agent, we just need mark the manifest has the deletiontimestamp, this should be finished by update function
| return mw.watcher, nil | ||
| } | ||
|
|
||
| func (mw *ManifestWorksAgentClient) Patch(ctx context.Context, name string, pt kubetypes.PatchType, data []byte, opts metav1.PatchOptions, subresources ...string) (result *workv1.ManifestWork, err error) { |
There was a problem hiding this comment.
we have starting to use patch a lot in ocm repo.
There was a problem hiding this comment.
add todo
need to implement this function
|
|
||
| func (c *ManifestWorksAgentClient) List(ctx context.Context, opts metav1.ListOptions) (*workv1.ManifestWorkList, error) { | ||
| klog.V(4).Infof("sync manifestworks") | ||
| // send resync request to fetch manifestworks from source |
There was a problem hiding this comment.
this is tricky, we only use list to resync?
There was a problem hiding this comment.
this only happens when the agent starts, if we want to resync in other time, I think we need call cloudevents resync function, or we don't do resync here? we provide a way to do resync when we build the clients
|
|
||
| var manifestWorkGR = schema.GroupResource{Group: workv1.GroupName, Resource: "manifestworks"} | ||
|
|
||
| // ManifestWorkWatcher implements the ManifestWorkInterface. It receives manifestworks spec from source by |
There was a problem hiding this comment.
| // ManifestWorkWatcher implements the ManifestWorkInterface. It receives manifestworks spec from source by | |
| // ManifestWorksAgentClient implements the ManifestWorkInterface. It receives manifestworks spec from source by |
skeeey
force-pushed
the
cloudevents-mw
branch
5 times, most recently
from
c45a1f1 to
ebe455c
Compare
|
now ManifestWorkResourceHandler send kube events to handle the works in local and ManifestWorksAgentClient sends works status to source |
skeeey
force-pushed
the
cloudevents-mw
branch
3 times, most recently
from
0096aa9 to
41b79d8
Compare
Signed-off-by: Wei Liu <liuweixa@redhat.com>
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: qiujian16, skeeey The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Summary
add cloudevents payload for manifestwork