I am using Oendaylight (carbon) to develop an SDN application consisting of multiple switches that connect to a controller. I want to be able to deploy different applications on different switches when they connect. How can I specify this? For example when openflow:1 connects, I want to deploy an L2 switch on it and when openflow:2 connects, I want to deploy a different application on it. Thanks.
First of all, you do not deploy applications on switches. Applications run on controller, you can add a logic which programs selected switches only.
What you essentially want to do is reactive programming; wait for events and act accordingly. This can be easily achieved by hooking the event listeners to the nodes in YANG model of the application. Any change in these nodes will be then notified to your application which can then do selective network programming.
In the example mentioned, you will need to use "InstanceIdentifier" object to identify which data model's events you are interested in listening.
InstanceIdentifier<Node> nodeID = InstanceIdentifier.builder(Nodes.class).child(Node.class, new NodeKey(node.getId())) .augmentation(FlowCapableNode.class)
.build();
Now simply register a listener to this IID by using DataBroker object's registerDataChangeListener method.
db.registerDataChangeListener(LogicalDatastoreType.CONFIGURATION, nodeID, this, AsyncDataBroker.DataChangeScope.SUBTREE);
At this point in time, you will be notified of any update (addition/modifification/deletion) of the switches you have registered for.
Finally to catch the event use/override DataChangeListener interface's onDataChanged method and add your fancy logic.
The similar logic can be fine grained to listen to activities on particular flow tables, flow rules, etc on the switch.
Related
To test that my application handles state transitions correctly, I'd like control over the lifecycle of moto's fake EC2 instances:
Rather than have instances start immediately in running, it would be nice to have them start in pending, let me confirm some things, and then explicitly transition them to running.
Relatedly, there are some actions I'd like to trigger in my tests when the instances switch to running.
Is any of this possible? I found InstanceBackend in moto's code -- is there a way for users to hook into or override methods there?
There are a few feature requests for more control over the transition cycle, but nothing has been implemented yet.
It is possible to use the internal API to set the status directly, as you said, using the InstanceBackend.
If you only have one instance, you can use the following code:
ec2_backend = moto.ec2.models.ec2_backends[my-region]
list(ec2_backend.reservations.values())[0].instances[0].state = "..."
If you have multiple reservations, you can use the reservation ID like this:
ec2_backend.reservations["r-7df1884b"].instances[0].state = "..."
Note that both AWS and Moto use two properties to track state, state and state_code. Only updating state may result in undefined behaviour, so you may want to update both to ensure they are in sync:
ec2_backend.reservations["r-7df1884b"].instances[0].state_code = ..
Note that this is an internal API, so changes to this data structure may occur without warning.
Use case is a regularly updated display of vehicle tracking data retrieved through a REST call, onto a central office screen, with no user interaction.
There is no single answer for this, but some alternatives to consider:
add some JavaScript to your screen that uses the JS setTimeout() method or something similar to reload the page
for a smoother result but a lot more effort write the section of the screen that needs to auto-update as a Vue component and use the standard websocket interface to send data to the browser to update the data in the HTML; this is generally best done using the NotificationMessage interfaces and methods in the Moqui API where the JavaScript client registers on a topic and gets a notification along with any others registered (structure the topic ID as needed to differentiate different feeds) and have a scheduled service job feed the notification topic
I have to create a particular simulation for a college project. The simulation should feature several mobile nodes cyclically switch between 802.11 access point and station modes. While in station mode, nodes should read the SSIDs of access points around them, and then they should change their SSID in AP mode accordingly. There is no need for connections or data exchange between the nodes beside the SSID reading.
Now, I've been through Omnet/Inet tutorials/documentation (all two of them), and I feel pretty much stuck.
What I could use right now is someone confirming my understanding of the framework giving me some directions on how exactly I should proceed.
From what I understand is Inet does not implement any direct/easy way to do what I'm trying to do. Most examples have fixed connections declared in NED files and hosts with a fixed status (AP or STA) defined in the .ini file.
So my question is basically how do I do that: do I need to extend a module (say, wirelessHost), modifying its runtime behaviour, or should I implement a new application (like UDPApp) to have my node read other SSIDs and change his accordingly? And what is the best way to access an host's SSID?
You may utilize two radios for each mobile node e.g. **.mobilenode[*].numRadios = 2 (see also example in /inet/examples/wireless/multiradio/).
The first radio operates as AP **.mobilenode[*].wlan[0].mgmtType = "Ieee80211MgmtAPSimplified" which has to adapt its SSID.
The second radio serves as STA **.mobilenode[*].wlan[1].mgmtType = "Ieee80211MgmtSTA". Now, you have to sub-class Ieee80211AgentSTA which handles the SSID scanning procedure and has to change the first radio's SSID upon new SSID detection. Then you utilize the adopted sub-class within the simulation. Finally, active scanning has to be activated **.mobilenode[*].wlan[1].agent.activeScan = true.
I working on high-scalability web site for learning purpose. I decided to use CQS pattern and some ideas of CQRS. I have separate write and read layers used by command handlers and event handlers which system sends and receives from message buses (two separate message- buses).
I have some problem dealing with commands. I read that command shouldn't return anything. And now the point is: for example I have a form on with user can create an event or for example change something in his profile (photo or name). After user clicked save i want to show him, his profile or add a new event to his wall. But how can I know that his profile has been already updated when command is only send to the bus ? I How connect idea of command and CRUD operations ? Or maybe this wrong idea at all ?
Well first off, the split should not be between commands and events, but rather between domain and read models. You can't really map CQRS commands to CRUD operations as a general rule, although most of the commands in your system will change the state of your repositories. I will give you a general overview of how this works. Say you want to add a user, you create a command AddUserCommand and assign an id to that message. On the back end, you have an handler for that command and you're right that the command does not return nothing. Once that command is handled you should publish and event reflecting the change: UserWasAddedEvent. The id of this message will be unique, but it can and should have an id related to the command which you created in the UI. Your read models should handle the event and update a read model with the command status (waiting, processing, completedOnError, completedSuccessfully) depending on the event you published. On the UI after you submited the command, you should start querying the read models whith the ID of the command you created to get the status and then update your UI accordigly.
Your right that CQRS handlers return void, but you should bear in mind that typically in an architecture like this, the backend should return the validation results of the submited commands, not the handler itself but the infrastucture around your cqrs handlers.
Just update te UI on the assumption the command succeeds - which most of the time it will.
If validation is required on the user input, you could run validation as the user types or tabs to increase the likelyhood the command will succeed.
I'm working on a small application using C++/wxWidgets, where several parts of the GUI need to be updated based on e.g. received UDP datagrams. More specifically, a secondary thread tries to keep a list of available "clients" in the network (which may come and go away) and e.g. corresponding comboboxes in the UI need to be updated to reflect the changes.
The documentation mentions that for this kind of thing EVT_UPDATE_UI would be a good choice. As far as I can understand from the sparse documentation, this event is sent automatically by the system and provides some support for assisted UI change.
However, I'd feel more comfortable using a more direct approach, i.e. where e.g. a window object could register/subscribe to receive notifications (either events or callbacks) upon particular events and another part of the code is sending out these notifications when required. I could do this in C++ using my own code, however I guess if wxWidgets already supports something like that, I should make use of it. However I haven't found anything in that regards.
So, the question is: does wxWidgets support this kind of notification system (or similar alternatives) or would I be best served coding my own?
AFAIK there is nothing directly usable in wxWidgets, but doing it on your own seems easy.
What I would do:
Create a wxEvtHandler-descendent class to hold the list of available "clients" in the network. Let this class have a wxCriticalSection, and use a wxCriticalSectionLocker for that in all methods that add or delete "clients".
Create a worker thread class by inheriting wxThread to handle your UDP datagrams, using blocking calls. The thread should directly call methods of the client list object whenever a client has to be added or removed. In these methods update the list of clients, and ::wxPostEvent() an event to itself (this will execute the whole notification calls in the main GUI thread).
Handle the event in the client list class, and notify all listeners that the list of clients has changed. The observer pattern seems to me a good fit. You could either call a method of all registered listeners directly, or send a wxCommandEvent to them.
Have you tried calling Update() on the widget(s) that change? Once you update the contents of the combo box, call Update(), and the contents should update.