I'm writing a custom controller that would listen to a CR I defined and update/create other resources (ones defined by Istio). All the examples out there show either how to handle native resources or custom ones created in the same package. But the resources I want to manage already exist and are registered in the cluster. So what I'm failing to understand is how to create or update them in Go code without describng them with my own types.
So I fgured out there is no way to do this without actually defining schemas for all the objects I want to manage in my own code.
I suppose it would be a good idea for anyone providing open source CRDs to also provide a go library that defines the types for them
Related
Whenever the deployment has been created needs to trigger a custom function or webhook. Does Kubernetes provide any option to do this?
Custom Resources are an extension to the Kubernetes API. Just having them standalone is not going to do anything functionally for you. If you need to perform a specific action upon change or deployment or bare existence of a given custom resource, you will need a custom controller that does that.
One of the possible implementations is an Operator. I specifically mention that, as it is fairly easy to create the controller alongside the custom resource definition using Operator SDK. However you can just create a custom resource definition and deploy a custom controller.
On a closing note: there are other ways your question is very broadly formulated so there is a vast variety of ways to answer, and this is just one option.
I can't seem to grasp the modules of dagger.
Should I create a new instance of a module each time I want to inject stuff?
Should I create only one instance of a module? If so where should I do it?
Is there a more complex example of fragments and activities used with dagger?
Thanks
You should think more about #Component than #Module. Modules just create objects that need further initialization. The actual work happens in Components, which modules are part of.
Should I create a new instance of a module each time I want to inject stuff?
You should create your module when you create the Component it is part of, since only this component is going to need it. If you find yourself creating the same module multiple times, you are most likely doing something wrong.
A module uses additional arguments (pass them in via the constructor) to create more complex objects. So if you were to have e.g. a UserModule you'd pass in the a user to create user dependent objects from the resulting component. If the user changes lose the old component and create a new module and a new component—the old objects should not be used anymore.
Keep the component where / when appropriate and be sure to use Scopes, since they determine the lifetime of your component.
Should I create only one instance of a module? If so where should I do it?
You most likely will just create a single instance of #Singleton annotated Components and Modules. In android you'd most likely keep the reference to the component (not the module!) in the Application or some real 'singleton'.
Is there a more complex example of fragments and activities used with dagger?
Try googling. There are lots of high quality tutorials with linked github repositories that go into much more depth and detail as would be possible here on SO. e.g. see Tasting dagger 2 on android.
In a custom plugin in custusX i use mServices->patientModelService->getPatientLandmarks()->setLandmark to programmatically alter some landmarks. I want to perform the registration with a already present volume.
In LandmarkPatientRegistrationWidget in org.custusx.registration.method.landmark, performRegistration() calls mServices.registrationService->doPatientRegistration().
However, I'm not sure whether my approach to get hold of a registrationService instance is right.
I have so far added org_custusx_registration to the CMakeLists.txt file and added "cxRegistrationService.h" and <cxRegServices.h> as includes.
Now I can define a RegServices mRegServices and initialize it in the constructor with the mContext of the plugin.
But do I create an own registration service or do I get access to the already existing? How can I get access to the already running registration service?
Your method correctly reuses the existing running registration service.
The default setup of CustusX register a single instance (object) implementing the cx::RegistrationService interface. The cx::RegServices helper class contains a cx::RegistrationServiceProxy, which acts as a smart pointer referring the object. Service objects are only created by the plugin that implement them: Users simply get access to these objects.
The RegistrationServiceProxy implements this using a ctkServiceTracker and related classes, see for example this tutorial on OSGi, section 5.4 (in java, but the principles apply).
I have a service IService that several components depend on. The components come and go depending on user actions.
It so happens that the implementation of IService is expensive, and I want 1 instance shared across all components. So far so good, I can use:
builder.RegisterType<ExpensiveStuff>().As<IService>().SingleInstance();
However, I don't want to ExpensiveStuff to live forever once built; I only want it to exist when one or more components holds a reference to it.
Is there a built in means of achieving this in Autofac?
I think you'll have to make sure that your usage of those dependencies happen within an instance scope.
The Orchard project could be a source of inspiration here. They use a set of scopes for Unit of Work; see the ShellContainerFactory.cs source file.
How should the configuration for an IoC container be organized? I know that registering by code should be placed at the highest level in an application, but what if an application had hundreds of dependencies that need to be registered? Same with XML configurations. I know that you can split up the XML configurations into multiple files, but that would seem like it would become a maintenance hassle if someone had to dig through multiple XML files.
Are there any best practices for organizing the registration of dependencies? From all the videos and tutorials that I've seen, the code used in the demo were simple enough to place in a single location. I have yet to come across a sample application that utilizes a large number of dependencies.
Autofac and others (eg Ninject) employ a module concept for this exact purpose. http://code.google.com/p/autofac/wiki/StructuringWithModules may be what you're looking for.
Hth
Nick
It would help a little if we knew if you were talking about any particular IoC Container.
Windsor, for example, allows you to define dependencies across a wide range of XML files (organised however you want), and simply included in the configuration. The structure should be in a format that makes sense. Have a file/folder for Controllers, Facilities, etc etc. A heirarchy of related items.
With something more code-oriented, such as Autofac, you could easily create a host of container configuration providers to power your configuration. With Hiro, you don't really need to do much configuration at all.
Regardless of the container used, they all provide facilites for convention-over-configuration based registrations, so that should be your first stop in cleaning up registrations. A great example would be to register all classes whose name ends in 'Controller' in an MVC application.