There is already a lot of analysis on new iPhone 5 C (for color) and 5 S (for sensors) including the usual fanboys such as Gruber, Siegler etc,.) and the haters (sarcastically indicating that “Google laughs at the new phone”)
I wanted to analyze it from a Product Manager’s perspective. Wall Street’s initial reaction is pessimism. Apple’s stock is down 5% the day after, but the fact that Apple doesn’t do what the Street wants it to do, gives me optimism.
Observations on the 5C
- The creation of 5C is interesting for its positioning and pricing. Apple diverged from its usual play of bumping the price down by $100. It packaged the product differently, added color and has made what is basically the iPhone 5 a “New Product”.
- 5C is now the “bread and butter” product for Apple. It is the first product featured on the website and the 5S is repeatedly positioned as a cutting edge product, and in many ways seems like a decoy.
- 5C is meant to “pull up” those who would have otherwise gone for the free product, but also meant to make them feel good about the product they have. (that color!)
- If you hate those 5C colors, you are not the target market! Anecdotally, I have heard that there is a lot of excitement about the colors from teens and new grads. Parents can expect to spend on the 5C.
- Apple 5C plus the $30 cases (which will be ALL margin) will keep the bottom line happy.
- The fact that the 32GB 5C and the 16GB 5S are the same price is a little head-scratching.
- I am surprised Apple let “hon” slip through the cracks.
Observations on the 5S
The 5S is very interesting from the perspective of iterative product development. I don’t know if it transpired this way, but I can envision someone doing the “Thai food approach” (aka the Similans approach) to each aspect of how iPhones are used and looking at how that experience can be fixed or improved. The idea is that you categorize / prioritize each area in a chili-meter, much like a Thai restaurant rates their food for spicy-ness. Here is my shot at de-constructing it.
- People take a lot of pictures on their iPhones. So, the thinking is “Let’s make the camera amazing””. The iPhone 6c (my name for the next year model when this camera becomes more mainstream) would become be the final nail in the coffin of Point and Shoot cameras, if they aren’t already dead. 3.5 chillies.
- People buy a lot of games on their iPhones. It amounts for 40% of the total app store downloads. So, Let’s put a 64-bit processor in there to make it FAST! Nintendo 3DS is a failure, and 2DS is now on notice. Legit gaming consoles (like Kinect/Xbox, Wii, Play Station) will be the DSLRs and handheld gaming consoles will die. (not that you already didnt know it). 4 chillies
- Better battery was on everyone’s wishlist: Oh yeah, and we have also added a 64-bit processor to it, which could make matters worse. How about we add a new processor (the M7) for some of the more battery intensive tasks. Oh, that also puts a whole new category of apps on steroids and helps us get into the market with Fitbit, Fuelband etc,.? SWEET! (although it could very well have been the other way around, where M7 was introduced to get into that category and had the benefit of preserving battery life) 5 chillies
- People tend to lose their phones and passcodes are a pain (According to Apple, 50% dont have it enabled). Typing complicated password for buying apps is a pain, and we have data that X% of users abandon buying apps (or In app purchases) at the password stage, so Let’s make that easy. Let’s have a fingerprint sensor to unlock the phone AND make it easy to buy apps/music from the phone. This makes our ecosystem even more stronger. Win-win. 3 chillies for painpoint and 5 chillies for upside
There you have it. This post is a bit of a brain dump, but figured I’d get back into the habit and also join in on this conversation. What are your thoughts? Which model are you going to buy?


Preparation time
less than 30 mins
Cooking time
less than 10 mins
Serves
Serves 4
Chung-he Huang shows you how to make this chicken, mushroom and egg stir-fry served in lettuce cups.
Heat a wok until smoking and add two tablespoons of the groundnut oil, then add the eggs and cook for one minute, or until scrambled. Remove from the wok and put to one side. Wipe the wok clean.
Heat the remaining groundnut oil in the wok until smoking, then add the garlic and ginger and stir fry for a few seconds. Add the chicken and cook for 1-2 minutes, or until lightly golden, then add the rice wine or sherry and stir well. Stir fry for a few seconds, then add the dried Chinese mushrooms and carrot and stir-fry for 1-2 minutes, or until the carrots are tender but with a bit of bite.
Add the gherkins, dried wood ear mushrooms, bamboo shoots and peanuts and mix well. Stir in the scrambled eggs. Season with the soy sauce, sesame oil and pepper and transfer to a serving dish.
To serve, place the dish in the centre of the table together with the lettuce leaves. Stuff each lettuce leaf with the filling and eat immediately.


Harry Potter and the philosopher's stone
by J. K. Rowling.
This book is about a boy who starts his journey in a magical school where he makes lots of friends and is faced with many challenges which he and his friends together overcome.
Harry Potter and the philosopher's stone is a great book. It is interesting and adventurous.
Other books by J. K. Rowling include Harry Potter and the Chamber's of secret, Harry Potter and the Goblet of fire, and Fantastic Beasts and where to find them.


{% for item in course.items %}
{{ item }}
{% endfor %}
--- layout: default title: "Courses" teaser: "We offer courses from ... up to ..." breadcrumb: true header: image_fullwidth: banner.png permalink: "/courses" ---


M
oonshot
B
i
n
g
o
How To Play
Astronaut
Bingo
Card
Rocket
Bingo
Card
Spaceship
Bingo
Card
UFO
Bingo
Card
Credits and Licenses
Code License: [
MIT License
-
download
]
Code Contributor (Game Off 2020): Korey Hinton [
GitHub Code
]
Included Code: Valentin Richard [
url-polyfill code
-
Download MIT License
]
Image Credits: [
stockio/freeiconspng/needpix
-
download
]
Audio Credits: [
Eric Taylor/SuperGamerMusic/NenadSimic
-
download
]


Psalms 106:42
Their enemies also oppressed them, and they were brought into subjection under their hand.


|
tesseract
4.00.00dev
|
#include <ccstruct.h>
Public Member Functions | |
| CCStruct () | |
| ~CCStruct () | |
| Public Member Functions inherited from tesseract::CUtil | |
| CUtil () | |
| ~CUtil () | |
| void | read_variables (const char *filename, bool global_only) |
| Public Member Functions inherited from tesseract::CCUtil | |
| CCUtil () | |
| virtual | ~CCUtil () |
| void | main_setup (const char *argv0, const char *basename) |
| CCUtil::main_setup - set location of tessdata and name of image. More... | |
| ParamsVectors * | params () |
Static Public Attributes | |
| static const double | kDescenderFraction = 0.25 |
| static const double | kXHeightFraction = 0.5 |
| static const double | kAscenderFraction = 0.25 |
| static const double | kXHeightCapRatio |
Additional Inherited Members | |
| Public Attributes inherited from tesseract::CCUtil | |
| STRING | datadir |
| STRING | imagebasename |
| STRING | lang |
| STRING | language_data_path_prefix |
| UNICHARSET | unicharset |
| UnicharAmbigs | unichar_ambigs |
| STRING | imagefile |
| STRING | directory |
| char * | m_data_sub_dir = "tessdata/" |
| int | ambigs_debug_level = 0 |
| bool | use_definite_ambigs_for_classifier = 0 |
| bool | use_ambigs_for_adaption = 0 |
Definition at line 25 of file ccstruct.h.
| tesseract::CCStruct::CCStruct | ( | ) |
Definition at line 31 of file ccstruct.cpp.
| tesseract::CCStruct::~CCStruct | ( | ) |
Definition at line 33 of file ccstruct.cpp.
|
static |
Definition at line 35 of file ccstruct.h.
|
static |
Definition at line 33 of file ccstruct.h.
|
static |
Definition at line 37 of file ccstruct.h.
|
static |
Definition at line 34 of file ccstruct.h.


This function updates project's file metadata. You can also use this call
to change filenames if you supply the name
argument.
file_meta_update( auth_token = NULL, project_id = NULL, file_id = NULL, name = NULL, file_type = c("text", "binary", "fasta", "csfasta", "fastq", "qual", "xsq", "sff", "bam", "bam_index", "illumina_export", "vcf", "sam", "bed", "archive", "juncs", "gtf", "gff", "enlis_genome"), qual_scale = c("sanger", "illumina13", "illumina15", "illumina18", "solexa"), seq_tech = c("454", "Helicos", "Illumina", "Solid", "IonTorrent"), sample = NULL, library = NULL, platform_unit = NULL, paired_end = NULL, ... )
| auth_token | auth token |
|---|---|
| project_id | ID of a project you want to access. |
| file_id | ID of a file you want to access. |
| name | File name. |
| file_type | File type. This metadata parameter is mandatory for each file. |
| qual_scale | Quality scale encoding. For FASTQ files, you must
either specify the quality score encoding sch which contains the
FASTQ quality scale detector wrapper. In that case, you can
specify the quality score encoding scheme by setting
|
| seq_tech | Sequencing technology. The |
| sample | Sample ID. You can use the |
| library | Library. You can set the library for the read using the
|
| platform_unit | Platform unit. You can set the platform unit
(e.g. lane for Illumina, or slide for SOLiD) using the |
| paired_end | Paired end. With paired-end reads, this parameter indicates if the read file is left end (1) or right end (2). For SOLiD CSFASTA files, paired end files 1 and 2 correspond to R3 and F3 files, respectively. |
| ... | parameters passed to sbgapi function |
parsed list of the returned json
For more information about file metadata, please check the File Metadata Documentation: https://developer.sbgenomics.com/platform/metadata.
token = '420b4672ebfc43bab48dc0d18a32fb6f' req = file_meta_update(token, project_id = '1c1d06d2-5862-48f6-b595-e0099b20937e', file_id = '530854e2e4b036506b803c7e', name = 'c.elegans_chr2_test.fastq', file_type = 'fastq', qual_scale = 'illumina13', seq_tech = 'Illumina')#> Error: HTTP Status 404: /1.1/project/1c1d06d2-5862-48f6-b595-e0099b20937e/file/530854e2e4b036506b803c7e not found


"JEDAIAH "(1.) Invoker of Jehovah. The son of Shimri, a chief Simeonite(1 Chronicles 4:37). (2.) One of those who repaired the walls of Jerusalem after the return from Babylon (Nehemiah 3:10). (3.) Knowing Jehovah. The chief of one of the courses of the priests (1 Chronicles 24:7). (4.) A priest in Jerusalem after the Exile (1 Chronicles 9:10).
"JEDAIAH "(1.) Invoker of Jehovah. The son of Shimri, a chief Simeonite(1 Chronicles 4:37).
(2.) One of those who repaired the walls of Jerusalem after the return from Babylon (Nehemiah 3:10).
(3.) Knowing Jehovah. The chief of one of the courses of the priests (1 Chronicles 24:7).
(4.) A priest in Jerusalem after the Exile (1 Chronicles 9:10).


We present DRaWR, a network-based method for ranking genes or properties related to a given gene set. Such related genes or properties are identified from among the nodes of a large, heterogeneous network of biological information. Our method involves a random walk with restarts, performed on an initial network with multiple node and edge types, preserving more of the original, specific property information than current methods that operate on homogeneous networks. In this first stage of our algorithm, we find the properties that are the most relevant to the given gene set and extract a subnetwork of the original network, comprising only the relevant properties. We then rerank genes by their similarity to the given gene set, based on a second random walk with restarts, performed on the above subnetwork.
| Version: | 1.0.1 |
| Depends: | R (≥ 3.0) |
| Imports: | Matrix, ROCR |
| Published: | 2016-02-05 |
| Author: | Charles Blatti [aut, cre] |
| Maintainer: | Charles Blatti <blatti at illinois.edu> |
| License: | GPL-2 |
| NeedsCompilation: | no |
| CRAN checks: | DRaWR results |
| Reference manual: | DRaWR.pdf |
| Package source: | DRaWR_1.0.1.tar.gz |
| Windows binaries: | r-devel: DRaWR_1.0.1.zip, r-release: DRaWR_1.0.1.zip, r-oldrel: DRaWR_1.0.1.zip |
| OS X binaries: | r-release: DRaWR_1.0.1.tgz, r-oldrel: DRaWR_1.0.1.tgz |
Please use the canonical form https://CRAN.R-project.org/package=DRaWR to link to this page.


{include file="common/header" /} {block name="content"}{/block} {include file="common/foot"/}
{block name="appendJs"}{/block}


My partner and I would like to design and develop a game using JavaScript as well as HTML. More specifically we would like to build a maze.
We will be using HTML for a good portion of this project, which we have become very familiar with thanks to the Getting To Know Each Other assignment as well as this proposal. For the project, we will have to do a lot of work with variables, which is another topic we have briefly touched upon in class.
For this project, we will need to do some work with JavaScript, which is a language we have mentioned, but not one we have into great detail about in this class. Learning how to create a maze within HTML will be a challenge in and of itself, so we will have to put a lot of work into figuring that out. We will also have to learn how to make our game piece move around the maze using HTML, so we will have to familiarize ourselves with many new concepts and functions within HTML need to do so.


Welcome to Ping-Pong; revenge of the coding challenge!
Epicodus strikes back!
A long time ago in a galaxy far, far away.........
Input any number, and this application will return a list of all the numbers between zero and your number. But wait; there is more!! The application will locate all numbers divisible by 3, and replace them by ping. It will replace all numbers divisible by five with pong. And last but not least; all numbers divisible by fifteen will be replaced with ping-pong!


Motorola Razr 2019’s European price confirmed, and it’s not cheap
by James PeckhamMotorola Razr 2019’s European price confirmed, and it’s not cheap
Pre-orders open next month
(Image credit: Future)
Motorola has revealed the European price for its Motorola Razr 2019 folding phone, and it's set to cost €1599 (about £1360, AU$2600).
We've previously heard that those in the US will be able to buy the phone for $1,500.
Those in the UK will be able to buy the handset exclusively on EE, but we don't currently know the exact SIM-free price for those in the UK. We also don't have any information on contract prices.
- Our time with the Moto Razr 2019
- Motorola Razr 2019 vs Samsung Galaxy Fold
- Will there be a Samsung Galaxy Fold 2?
Exactly when you'll be able to buy the phone in Europe is currently unclear too, but some markets will be able to pre-order the Motorola Razr 2019 from December. We know for certain that the phone will be coming to the UK and Italy at some point in 2020.
The Motorola Razr 2019 is also set to get a two-year warranty for those in Europe.
That's double what is offered in the US, while Motorola told press that it would also offer "a world class package" for those who have issues with the phone when the warranty has ended.


| PostgreSQL 9.6.15 Documentation | |||
|---|---|---|---|
| Prev | Up | Chapter 59. Index Access Method Interface Definition | Next |
Each index access method is described by a row in the pg_am system catalog. The pg_am entry specifies a name and a handler function for the access method. These entries can be created and deleted using the CREATE ACCESS METHOD and DROP ACCESS METHOD SQL commands.
An index access method handler function must be declared to accept a single argument of type internal and to return the pseudo-type index_am_handler. The argument is a dummy value that simply serves to prevent handler functions from being called directly from SQL commands. The result of the function must be a palloc'd struct of type IndexAmRoutine, which contains everything that the core code needs to know to make use of the index access method. The IndexAmRoutine struct, also called the access method's API struct, includes fields specifying assorted fixed properties of the access method, such as whether it can support multicolumn indexes. More importantly, it contains pointers to support functions for the access method, which do all of the real work to access indexes. These support functions are plain C functions and are not visible or callable at the SQL level. The support functions are described in Section 59.2.
The structure IndexAmRoutine is defined thus:
typedef struct IndexAmRoutine { NodeTag type; /* * Total number of strategies (operators) by which we can traverse/search * this AM. Zero if AM does not have a fixed set of strategy assignments. */ uint16 amstrategies; /* total number of support functions that this AM uses */ uint16 amsupport; /* does AM support ORDER BY indexed column's value? */ bool amcanorder; /* does AM support ORDER BY result of an operator on indexed column? */ bool amcanorderbyop; /* does AM support backward scanning? */ bool amcanbackward; /* does AM support UNIQUE indexes? */ bool amcanunique; /* does AM support multi-column indexes? */ bool amcanmulticol; /* does AM require scans to have a constraint on the first index column? */ bool amoptionalkey; /* does AM handle ScalarArrayOpExpr quals? */ bool amsearcharray; /* does AM handle IS NULL/IS NOT NULL quals? */ bool amsearchnulls; /* can index storage data type differ from column data type? */ bool amstorage; /* can an index of this type be clustered on? */ bool amclusterable; /* does AM handle predicate locks? */ bool ampredlocks; /* type of data stored in index, or InvalidOid if variable */ Oid amkeytype; /* interface functions */ ambuild_function ambuild; ambuildempty_function ambuildempty; aminsert_function aminsert; ambulkdelete_function ambulkdelete; amvacuumcleanup_function amvacuumcleanup; amcanreturn_function amcanreturn; /* can be NULL */ amcostestimate_function amcostestimate; amoptions_function amoptions; amproperty_function amproperty; /* can be NULL */ amvalidate_function amvalidate; ambeginscan_function ambeginscan; amrescan_function amrescan; amgettuple_function amgettuple; /* can be NULL */ amgetbitmap_function amgetbitmap; /* can be NULL */ amendscan_function amendscan; ammarkpos_function ammarkpos; /* can be NULL */ amrestrpos_function amrestrpos; /* can be NULL */ } IndexAmRoutine;
To be useful, an index access method must also have one or more operator families and operator classes defined in pg_opfamily, pg_opclass, pg_amop, and pg_amproc. These entries allow the planner to determine what kinds of query qualifications can be used with indexes of this access method. Operator families and classes are described in Section 36.14, which is prerequisite material for reading this chapter.
An individual index is defined by a pg_class entry that describes it as a physical relation, plus a pg_index entry that shows the logical content of the index — that is, the set of index columns it has and the semantics of those columns, as captured by the associated operator classes. The index columns (key values) can be either simple columns of the underlying table or expressions over the table rows. The index access method normally has no interest in where the index key values come from (it is always handed precomputed key values) but it will be very interested in the operator class information in pg_index. Both of these catalog entries can be accessed as part of the Relation data structure that is passed to all operations on the index.
Some of the flag fields of IndexAmRoutine have nonobvious implications. The requirements of amcanunique are discussed in Section 59.5. The amcanmulticol flag asserts that the access method supports multicolumn indexes, while amoptionalkey asserts that it allows scans where no indexable restriction clause is given for the first index column. When amcanmulticol is false, amoptionalkey essentially says whether the access method supports full-index scans without any restriction clause. Access methods that support multiple index columns must support scans that omit restrictions on any or all of the columns after the first; however they are permitted to require some restriction to appear for the first index column, and this is signaled by setting amoptionalkey false. One reason that an index AM might set amoptionalkey false is if it doesn't index null values. Since most indexable operators are strict and hence cannot return true for null inputs, it is at first sight attractive to not store index entries for null values: they could never be returned by an index scan anyway. However, this argument fails when an index scan has no restriction clause for a given index column. In practice this means that indexes that have amoptionalkey true must index nulls, since the planner might decide to use such an index with no scan keys at all. A related restriction is that an index access method that supports multiple index columns must support indexing null values in columns after the first, because the planner will assume the index can be used for queries that do not restrict these columns. For example, consider an index on (a,b) and a query with WHERE a = 4. The system will assume the index can be used to scan for rows with a = 4, which is wrong if the index omits rows where b is null. It is, however, OK to omit rows where the first indexed column is null. An index access method that does index nulls may also set amsearchnulls, indicating that it supports IS NULL and IS NOT NULL clauses as search conditions.


Tristan and Blake Barrass, 13 and 14, both died of asphyxiation.
But it was unclear whether the strangling or the bin bags were the cause, Sheffield Crown Court heard as their mum, Sarah Barrass, and family member Brandon Machin were sentenced on Monday.
We'll be bringing you the very latest updates, pictures and video on this breaking news story.
Please check back regularly for updates on this developing story here at Mirror.co.uk.
For the latest news and breaking news visit Mirror.co.uk/news.
Get all the big headlines, pictures, analysis, opinion and video on the stories that matter to you.
Follow us on Twitter @DailyMirror - the official Daily Mirror & Mirror Online Twitter account - real news in real time.
We're also on Facebook/dailymirror - your must-see news, features, videos and pictures throughout the day from the Daily Mirror, Sunday Mirror and Mirror Online.


British banks are generally not accepting the notes and technically, they should not leave the country. It means the shape of the cube alone is not enough to protect it from being copied. Patents protect inventions for a certain amount of time, while trademarks intellectual property owners exclusive rights to their designs.
Facebook said that it planned to create a measurement council to give businesses a say in the development of future metrics, and that it had also created a new internal review process. The latest mistakes might appear relatively minor in nature, but one digital marketing expert said they undermined confidence in the social network.


[two weeks and 4.5 days after]
punt
[the 2nd monday of]
ordinal
[this]
relative
[feb]
root
[at 2pm]
time
[kabul time]
timezone


Muni
Bus information
Auxiliary
README
,
GITHUB
Manuals
muni(1)
muni route information and prediction tool
See Also
Next Muni
Copyright © 2011 Jeff Remer


Compatibility with other standards
Although the HARP data format aims to be compatible with (or orthogonal to) other data format standards, this may not always be fully possible. Below we detail some of the known differences with existing standards.
netCDF-CF
The HARP data format standard is to a large extent compatible with the netCDF-CF standard. This means that HARP attributes either use the same definition as used for netCDF-CF or the attributes are not governed by netCDF-CF. And vice versa, HARP allows (and ignores) attributes that are not HARP specific.
For the naming convention of variables, in HARP these apply to the actual variable names.
This is complementary to the naming convention for variables used in netCDF-CF which is performed by means of the
standard_name
variable attribute.
There are however a few differences between the conventions used in HARP and netCDF-CF. These are:
In HARP the vertical dimension in a variable always comes after the latitude and longitude dimensions, whereas in netCDF-CF the recommendation (not a requirement) is to have the vertical dimension before latitude and longitude.
In netCDF-CF a specific type of dimension can be used only once as dimension of a variable. This is not the case in HARP where a specific dimension may occur more than once. For instance, HARP allows you to use a
{vertical,vertical}
dimension for a vertical correlation matrix, whereas in netCDF-CF the second vertical dimension needs to be a differently named dimension.Axis variables in HARP can generally be considered ‘auxiliary coordinate variables’ (using netCDF-CF terminology) but rarely strict ‘coordinate variables’. Note that HARP does not require a pre-identification of axis variables; none of the dimensions have a fixed axis variable associated with them (or require presence of an axis variable); different variables in a product can function as axis variable for a dimension dynamically, depending on the operation to be performed.
Due to the way axis variables and dimensions are defined in HARP, HARP products do not meet the netCDF-CF requirement that any used dimension (with length greater than one) that is latitude, longitude, vertical, or time needs to have a ‘coordinate variable’ (using same name and single dimension).
HARP axis variables can be 2-dimensional (e.g.
{time,axis}
) to allow for e.g. a different altitude grid per time sample (where the actualaxis
length can also differ per time and will then contain fill values at the end to represent shorter lengths). NetCDF-CF supports this as ‘incomplete multidimensional array representation’ of ‘auxiliary coordinate variables’. However, other multi-dimensional ‘auxiliary coordinate variable’ cases in netCDF-CF generally do not have a HARP axis variable equivalent. For instance, for the 2-dimensional lat/lon coordinate variables case (usinglon(j,i)
andlat(j,i)
) the coordinate variables would not be considered axis variables by HARP.


{% extends 'base.html' %} {% block content %}
No meetings are available.
Click to See all meetings in {{area.area}}


OverlayUFOs was created in 2012 by David Jonathan Ross for Font Bureau. It may or may not work the way you want it to.
In the current glyph window, this will present a view of the same glyph from a separate UFO or set of UFOs.
This does NOT import the UFO into a background layer. Instead, it renders a outline directly from the UFO into the glyph window view.
I use this to compare a typeface across styles, or to check for consistency within a family.
Source Fonts: The default source font list is AllFonts() at the time the dialog is opened. The refresh button will return this list to AllFonts().
Adding Fonts: You can manually add fonts by selecting a UFO file. To save time and reduce clutter, the UFO will open without a Robofont interface.
Removing Fonts: There are buttons for removing selected fonts and for clearing the source font list.
Possible Issue? The source font is drawn on top of the current font, instead of behind it. So, it is good to select a color with a low opacity.
Known Bug: If the glyph window for both source and current fonts are open, it is possible to select and inadvertently edit the source outline in the current window. I don't know how to solve this.
Possible Improvement? Add options to scale the source font.
Possible Improvement? Set different colors, fill settings for each font?
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


|
MoveToCode
|
Identifier of a key combination or mouse button for generic input binding. More...
Public Types | |
| enum class | KeyType : int { None = 0 , Mouse = 1 , Key = 2 } |
| The type of value encoded in the code property. More... | |
| enum class | MouseButton : int { Left = 0 , Right = 1 , Middle = 2 , Button3 = 3 , Button4 = 4 , Button5 = 5 , Button6 = 6 , Button7 = 7 } |
| Enum for interpreting the mouse button integer index. More... | |
Public Member Functions | |
| override string | ToString () |
| bool | TryGetKeyCode (out KeyCode keyCode) |
| Try to convert the binding to a KeyCode. More... | |
| bool | TryGetMouseButton (out int mouseButton) |
| Try to convert the binding to a mouse button. More... | |
| bool | TryGetMouseButton (out MouseButton mouseButton) |
| Try to convert the binding to a mouse button. More... | |
Static Public Member Functions | |
| static | KeyBinding () |
| static KeyBinding | Unbound () |
| Create a default empty binding. More... | |
| static KeyBinding | FromKey (KeyCode keyCode) |
| Create a binding for a keyboard key. More... | |
| static KeyBinding | FromMouseButton (int mouseButton) |
| Create a binding for a mouse button. More... | |
| static KeyBinding | FromMouseButton (MouseButton mouseButton) |
| Create a binding for a mouse button. More... | |
Properties | |
| KeyType | BindingType [get] |
| Type of input this binding maps to. More... | |
Identifier of a key combination or mouse button for generic input binding.
This encodes either a KeyCode with optional modifiers or a mouse button index.
|
strong |
|
strong |
|
static |
|
static |
Create a binding for a keyboard key.
|
static |
Create a binding for a mouse button.
|
static |
Create a binding for a mouse button.
| override string Microsoft.MixedReality.Toolkit.Input.KeyBinding.ToString | ( | ) |
| bool Microsoft.MixedReality.Toolkit.Input.KeyBinding.TryGetKeyCode | ( | out KeyCode | keyCode | ) |
Try to convert the binding to a KeyCode.
| bool Microsoft.MixedReality.Toolkit.Input.KeyBinding.TryGetMouseButton | ( | out int | mouseButton | ) |
Try to convert the binding to a mouse button.
| bool Microsoft.MixedReality.Toolkit.Input.KeyBinding.TryGetMouseButton | ( | out MouseButton | mouseButton | ) |
Try to convert the binding to a mouse button.
|
static |
Create a default empty binding.
|
get |
Type of input this binding maps to.


Create a new site
Site Name
Please use the map below to select or search a location:
Latitude, Longitude, and Elevation
Continue
Want to head back to the home page?
Click here!


--- layout: post title: Glimpse - A client side look at whats going on in your server date: '2011-07-09T02:50:00.001+01:00' author: solrevdev tags: modified_time: '2011-07-09T02:50:51.795+01:00' blogger_id: tag:blogger.com,1999:blog-31446756.post-4549206117266585003 blogger_orig_url: http://www.solrevdev.com/2011/07/glimpse-client-side-look-at-whats-going.html ---
This looks amazing. Added to my list of things to play with when I have time!


ovn-architecture(7) Open vSwitch Manual ovn-architecture(7) NAME ovn-architecture - Open Virtual Network architecture DESCRIPTION OVN, the Open Virtual Network, is a system to support virtual network abstraction. OVN complements the existing capabilities of OVS to add native support for virtual network abstractions, such as virtual L2 and L3 overlays and security groups. Services such as DHCP are also desir‐ able features. Just like OVS, OVN’s design goal is to have a produc‐ tion-quality implementation that can operate at significant scale. An OVN deployment consists of several components: • A Cloud Management System (CMS), which is OVN’s ultimate client (via its users and administrators). OVN integra‐ tion requires installing a CMS-specific plugin and re‐ lated software (see below). OVN initially targets Open‐ Stack as CMS. We generally speak of ``the’’ CMS, but one can imagine scenarios in which multiple CMSes manage different parts of an OVN deployment. • An OVN Database physical or virtual node (or, eventually, cluster) installed in a central location. • One or more (usually many) hypervisors. Hypervisors must run Open vSwitch and implement the interface described in IntegrationGuide.rst in the OVS source tree. Any hypervi‐ sor platform supported by Open vSwitch is acceptable. • Zero or more gateways. A gateway extends a tunnel-based logical network into a physical network by bidirection‐ ally forwarding packets between tunnels and a physical Ethernet port. This allows non-virtualized machines to participate in logical networks. A gateway may be a phys‐ ical host, a virtual machine, or an ASIC-based hardware switch that supports the vtep(5) schema. Hypervisors and gateways are together called transport node or chassis. The diagram below shows how the major components of OVN and related software interact. Starting at the top of the diagram, we have: • The Cloud Management System, as defined above. • The OVN/CMS Plugin is the component of the CMS that in‐ terfaces to OVN. In OpenStack, this is a Neutron plugin. The plugin’s main purpose is to translate the CMS’s no‐ tion of logical network configuration, stored in the CMS’s configuration database in a CMS-specific format, into an intermediate representation understood by OVN. This component is necessarily CMS-specific, so a new plugin needs to be developed for each CMS that is inte‐ grated with OVN. All of the components below this one in the diagram are CMS-independent. • The OVN Northbound Database receives the intermediate representation of logical network configuration passed down by the OVN/CMS Plugin. The database schema is meant to be ``impedance matched’’ with the concepts used in a CMS, so that it directly supports notions of logical switches, routers, ACLs, and so on. See ovn-nb(5) for de‐ tails. The OVN Northbound Database has only two clients: the OVN/CMS Plugin above it and ovn-northd below it. • ovn-northd(8) connects to the OVN Northbound Database above it and the OVN Southbound Database below it. It translates the logical network configuration in terms of conventional network concepts, taken from the OVN North‐ bound Database, into logical datapath flows in the OVN Southbound Database below it. • The OVN Southbound Database is the center of the system. Its clients are ovn-northd(8) above it and ovn-con‐ troller(8) on every transport node below it. The OVN Southbound Database contains three kinds of data: Physical Network (PN) tables that specify how to reach hypervisor and other nodes, Logical Network (LN) tables that describe the logical network in terms of ``logical datapath flows,’’ and Binding tables that link logical network components’ locations to the physical network. The hypervisors populate the PN and Port_Binding tables, whereas ovn-northd(8) populates the LN tables. OVN Southbound Database performance must scale with the number of transport nodes. This will likely require some work on ovsdb-server(1) as we encounter bottlenecks. Clustering for availability may be needed. The remaining components are replicated onto each hypervisor: • ovn-controller(8) is OVN’s agent on each hypervisor and software gateway. Northbound, it connects to the OVN Southbound Database to learn about OVN configuration and status and to populate the PN table and the Chassis col‐ umn in Binding table with the hypervisor’s status. South‐ bound, it connects to ovs-vswitchd(8) as an OpenFlow con‐ troller, for control over network traffic, and to the lo‐ cal ovsdb-server(1) to allow it to monitor and control Open vSwitch configuration. • ovs-vswitchd(8) and ovsdb-server(1) are conventional com‐ ponents of Open vSwitch.  The CMS, through its OVN/CMS plugin, passes the logical network configuration to ovn-northd via the northbound database. In turn, ovn-northd compiles the configuration into a lower-level form and passes it to all of the chassis via the southbound database. Status information in OVN flows from south to north. OVN currently pro‐ vides only a few forms of status information. First, ovn-northd popu‐ lates the up column in the northbound Logical_Switch_Port table: if a logical port’s chassis column in the southbound Port_Binding table is nonempty, it sets up to true, otherwise to false. This allows the CMS to detect when a VM’s networking has come up. Second, OVN provides feedback to the CMS on the realization of its con‐ figuration, that is, whether the configuration provided by the CMS has taken effect. This feature requires the CMS to participate in a se‐ quence number protocol, which works the following way: 1. When the CMS updates the configuration in the northbound database, as part of the same transaction, it increments the value of the nb_cfg column in the NB_Global table. (This is only necessary if the CMS wants to know when the configura‐ tion has been realized.) 2. When ovn-northd updates the southbound database based on a given snapshot of the northbound database, it copies nb_cfg from northbound NB_Global into the southbound database SB_Global table, as part of the same transaction. (Thus, an observer monitoring both databases can determine when the southbound database is caught up with the northbound.) 3. After ovn-northd receives confirmation from the southbound database server that its changes have committed, it updates sb_cfg in the northbound NB_Global table to the nb_cfg ver‐ sion that was pushed down. (Thus, the CMS or another ob‐ server can determine when the southbound database is caught up without a connection to the southbound database.) 4. The ovn-controller process on each chassis receives the up‐ dated southbound database, with the updated nb_cfg. This process in turn updates the physical flows installed in the chassis’s Open vSwitch instances. When it receives confirma‐ tion from Open vSwitch that the physical flows have been up‐ dated, it updates nb_cfg in its own Chassis record in the southbound database. 5. ovn-northd monitors the nb_cfg column in all of the Chassis records in the southbound database. It keeps track of the minimum value among all the records and copies it into the hv_cfg column in the northbound NB_Global table. (Thus, the CMS or another observer can determine when all of the hyper‐ visors have caught up to the northbound configuration.) Chassis Setup Each chassis in an OVN deployment must be configured with an Open vSwitch bridge dedicated for OVN’s use, called the integration bridge. System startup scripts may create this bridge prior to starting ovn-controller if desired. If this bridge does not exist when ovn-con‐ troller starts, it will be created automatically with the default con‐ figuration suggested below. The ports on the integration bridge in‐ clude: • On any chassis, tunnel ports that OVN uses to maintain logical network connectivity. ovn-controller adds, up‐ dates, and removes these tunnel ports. • On a hypervisor, any VIFs that are to be attached to log‐ ical networks. The hypervisor itself, or the integration between Open vSwitch and the hypervisor (described in In‐ tegrationGuide.rst) takes care of this. (This is not part of OVN or new to OVN; this is pre-existing integration work that has already been done on hypervisors that sup‐ port OVS.) • On a gateway, the physical port used for logical network connectivity. System startup scripts add this port to the bridge prior to starting ovn-controller. This can be a patch port to another bridge, instead of a physical port, in more sophisticated setups. Other ports should not be attached to the integration bridge. In par‐ ticular, physical ports attached to the underlay network (as opposed to gateway ports, which are physical ports attached to logical networks) must not be attached to the integration bridge. Underlay physical ports should instead be attached to a separate Open vSwitch bridge (they need not be attached to any bridge at all, in fact). The integration bridge should be configured as described below. The ef‐ fect of each of these settings is documented in ovs-vswitchd.conf.db(5): fail-mode=secure Avoids switching packets between isolated logical net‐ works before ovn-controller starts up. See Controller Failure Settings in ovs-vsctl(8) for more information. other-config:disable-in-band=true Suppresses in-band control flows for the integration bridge. It would be unusual for such flows to show up anyway, because OVN uses a local controller (over a Unix domain socket) instead of a remote controller. It’s pos‐ sible, however, for some other bridge in the same system to have an in-band remote controller, and in that case this suppresses the flows that in-band control would or‐ dinarily set up. Refer to the documentation for more in‐ formation. The customary name for the integration bridge is br-int, but another name may be used. Logical Networks A logical network implements the same concepts as physical networks, but they are insulated from the physical network with tunnels or other encapsulations. This allows logical networks to have separate IP and other address spaces that overlap, without conflicting, with those used for physical networks. Logical network topologies can be arranged with‐ out regard for the topologies of the physical networks on which they run. Logical network concepts in OVN include: • Logical switches, the logical version of Ethernet switches. • Logical routers, the logical version of IP routers. Logi‐ cal switches and routers can be connected into sophisti‐ cated topologies. • Logical datapaths are the logical version of an OpenFlow switch. Logical switches and routers are both implemented as logical datapaths. • Logical ports represent the points of connectivity in and out of logical switches and logical routers. Some common types of logical ports are: • Logical ports representing VIFs. • Localnet ports represent the points of connectiv‐ ity between logical switches and the physical net‐ work. They are implemented as OVS patch ports be‐ tween the integration bridge and the separate Open vSwitch bridge that underlay physical ports attach to. • Logical patch ports represent the points of con‐ nectivity between logical switches and logical routers, and in some cases between peer logical routers. There is a pair of logical patch ports at each such point of connectivity, one on each side. • Localport ports represent the points of local con‐ nectivity between logical switches and VIFs. These ports are present in every chassis (not bound to any particular one) and traffic from them will never go through a tunnel. A localport is expected to only generate traffic destined for a local des‐ tination, typically in response to a request it received. One use case is how OpenStack Neutron uses a localport port for serving metadata to VM’s residing on every hypervisor. A metadata proxy process is attached to this port on every host and all VM’s within the same network will reach it at the same IP/MAC address without any traffic being sent over a tunnel. Further details can be seen at https://docs.openstack.org/developer/networking- ovn/design/metadata_api.html. Life Cycle of a VIF Tables and their schemas presented in isolation are difficult to under‐ stand. Here’s an example. A VIF on a hypervisor is a virtual network interface attached either to a VM or a container running directly on that hypervisor (This is dif‐ ferent from the interface of a container running inside a VM). The steps in this example refer often to details of the OVN and OVN Northbound database schemas. Please see ovn-sb(5) and ovn-nb(5), re‐ spectively, for the full story on these databases. 1. A VIF’s life cycle begins when a CMS administrator creates a new VIF using the CMS user interface or API and adds it to a switch (one implemented by OVN as a logical switch). The CMS updates its own configuration. This includes associating unique, persistent identifier vif-id and Ethernet address mac with the VIF. 2. The CMS plugin updates the OVN Northbound database to in‐ clude the new VIF, by adding a row to the Logi‐ cal_Switch_Port table. In the new row, name is vif-id, mac is mac, switch points to the OVN logical switch’s Logi‐ cal_Switch record, and other columns are initialized appro‐ priately. 3. ovn-northd receives the OVN Northbound database update. In turn, it makes the corresponding updates to the OVN South‐ bound database, by adding rows to the OVN Southbound data‐ base Logical_Flow table to reflect the new port, e.g. add a flow to recognize that packets destined to the new port’s MAC address should be delivered to it, and update the flow that delivers broadcast and multicast packets to include the new port. It also creates a record in the Binding table and populates all its columns except the column that identifies the chassis. 4. On every hypervisor, ovn-controller receives the Logi‐ cal_Flow table updates that ovn-northd made in the previous step. As long as the VM that owns the VIF is powered off, ovn-controller cannot do much; it cannot, for example, ar‐ range to send packets to or receive packets from the VIF, because the VIF does not actually exist anywhere. 5. Eventually, a user powers on the VM that owns the VIF. On the hypervisor where the VM is powered on, the integration between the hypervisor and Open vSwitch (described in Inte‐ grationGuide.rst) adds the VIF to the OVN integration bridge and stores vif-id in external_ids:iface-id to indicate that the interface is an instantiation of the new VIF. (None of this code is new in OVN; this is pre-existing integration work that has already been done on hypervisors that support OVS.) 6. On the hypervisor where the VM is powered on, ovn-controller notices external_ids:iface-id in the new Interface. In re‐ sponse, in the OVN Southbound DB, it updates the Binding ta‐ ble’s chassis column for the row that links the logical port from external_ids: iface-id to the hypervisor. Afterward, ovn-controller updates the local hypervisor’s OpenFlow ta‐ bles so that packets to and from the VIF are properly han‐ dled. 7. Some CMS systems, including OpenStack, fully start a VM only when its networking is ready. To support this, ovn-northd notices the chassis column updated for the row in Binding table and pushes this upward by updating the up column in the OVN Northbound database’s Logical_Switch_Port table to indicate that the VIF is now up. The CMS, if it uses this feature, can then react by allowing the VM’s execution to proceed. 8. On every hypervisor but the one where the VIF resides, ovn-controller notices the completely populated row in the Binding table. This provides ovn-controller the physical lo‐ cation of the logical port, so each instance updates the OpenFlow tables of its switch (based on logical datapath flows in the OVN DB Logical_Flow table) so that packets to and from the VIF can be properly handled via tunnels. 9. Eventually, a user powers off the VM that owns the VIF. On the hypervisor where the VM was powered off, the VIF is deleted from the OVN integration bridge. 10. On the hypervisor where the VM was powered off, ovn-con‐ troller notices that the VIF was deleted. In response, it removes the Chassis column content in the Binding table for the logical port. 11. On every hypervisor, ovn-controller notices the empty Chas‐ sis column in the Binding table’s row for the logical port. This means that ovn-controller no longer knows the physical location of the logical port, so each instance updates its OpenFlow table to reflect that. 12. Eventually, when the VIF (or its entire VM) is no longer needed by anyone, an administrator deletes the VIF using the CMS user interface or API. The CMS updates its own configu‐ ration. 13. The CMS plugin removes the VIF from the OVN Northbound data‐ base, by deleting its row in the Logical_Switch_Port table. 14. ovn-northd receives the OVN Northbound update and in turn updates the OVN Southbound database accordingly, by removing or updating the rows from the OVN Southbound database Logi‐ cal_Flow table and Binding table that were related to the now-destroyed VIF. 15. On every hypervisor, ovn-controller receives the Logi‐ cal_Flow table updates that ovn-northd made in the previous step. ovn-controller updates OpenFlow tables to reflect the update, although there may not be much to do, since the VIF had already become unreachable when it was removed from the Binding table in a previous step. Life Cycle of a Container Interface Inside a VM OVN provides virtual network abstractions by converting information written in OVN_NB database to OpenFlow flows in each hypervisor. Secure virtual networking for multi-tenants can only be provided if OVN con‐ troller is the only entity that can modify flows in Open vSwitch. When the Open vSwitch integration bridge resides in the hypervisor, it is a fair assumption to make that tenant workloads running inside VMs cannot make any changes to Open vSwitch flows. If the infrastructure provider trusts the applications inside the con‐ tainers not to break out and modify the Open vSwitch flows, then con‐ tainers can be run in hypervisors. This is also the case when contain‐ ers are run inside the VMs and Open vSwitch integration bridge with flows added by OVN controller resides in the same VM. For both the above cases, the workflow is the same as explained with an example in the previous section ("Life Cycle of a VIF"). This section talks about the life cycle of a container interface (CIF) when containers are created in the VMs and the Open vSwitch integration bridge resides inside the hypervisor. In this case, even if a container application breaks out, other tenants are not affected because the con‐ tainers running inside the VMs cannot modify the flows in the Open vSwitch integration bridge. When multiple containers are created inside a VM, there are multiple CIFs associated with them. The network traffic associated with these CIFs need to reach the Open vSwitch integration bridge running in the hypervisor for OVN to support virtual network abstractions. OVN should also be able to distinguish network traffic coming from different CIFs. There are two ways to distinguish network traffic of CIFs. One way is to provide one VIF for every CIF (1:1 model). This means that there could be a lot of network devices in the hypervisor. This would slow down OVS because of all the additional CPU cycles needed for the management of all the VIFs. It would also mean that the entity cre‐ ating the containers in a VM should also be able to create the corre‐ sponding VIFs in the hypervisor. The second way is to provide a single VIF for all the CIFs (1:many model). OVN could then distinguish network traffic coming from differ‐ ent CIFs via a tag written in every packet. OVN uses this mechanism and uses VLAN as the tagging mechanism. 1. A CIF’s life cycle begins when a container is spawned inside a VM by the either the same CMS that created the VM or a tenant that owns that VM or even a container Orchestration System that is different than the CMS that initially created the VM. Whoever the entity is, it will need to know the vif- id that is associated with the network interface of the VM through which the container interface’s network traffic is expected to go through. The entity that creates the con‐ tainer interface will also need to choose an unused VLAN in‐ side that VM. 2. The container spawning entity (either directly or through the CMS that manages the underlying infrastructure) updates the OVN Northbound database to include the new CIF, by adding a row to the Logical_Switch_Port table. In the new row, name is any unique identifier, parent_name is the vif- id of the VM through which the CIF’s network traffic is ex‐ pected to go through and the tag is the VLAN tag that iden‐ tifies the network traffic of that CIF. 3. ovn-northd receives the OVN Northbound database update. In turn, it makes the corresponding updates to the OVN South‐ bound database, by adding rows to the OVN Southbound data‐ base’s Logical_Flow table to reflect the new port and also by creating a new row in the Binding table and populating all its columns except the column that identifies the chas‐ sis. 4. On every hypervisor, ovn-controller subscribes to the changes in the Binding table. When a new row is created by ovn-northd that includes a value in parent_port column of Binding table, the ovn-controller in the hypervisor whose OVN integration bridge has that same value in vif-id in ex‐ ternal_ids:iface-id updates the local hypervisor’s OpenFlow tables so that packets to and from the VIF with the particu‐ lar VLAN tag are properly handled. Afterward it updates the chassis column of the Binding to reflect the physical loca‐ tion. 5. One can only start the application inside the container af‐ ter the underlying network is ready. To support this, ovn-northd notices the updated chassis column in Binding ta‐ ble and updates the up column in the OVN Northbound data‐ base’s Logical_Switch_Port table to indicate that the CIF is now up. The entity responsible to start the container appli‐ cation queries this value and starts the application. 6. Eventually the entity that created and started the con‐ tainer, stops it. The entity, through the CMS (or directly) deletes its row in the Logical_Switch_Port table. 7. ovn-northd receives the OVN Northbound update and in turn updates the OVN Southbound database accordingly, by removing or updating the rows from the OVN Southbound database Logi‐ cal_Flow table that were related to the now-destroyed CIF. It also deletes the row in the Binding table for that CIF. 8. On every hypervisor, ovn-controller receives the Logi‐ cal_Flow table updates that ovn-northd made in the previous step. ovn-controller updates OpenFlow tables to reflect the update. Architectural Physical Life Cycle of a Packet This section describes how a packet travels from one virtual machine or container to another through OVN. This description focuses on the phys‐ ical treatment of a packet; for a description of the logical life cycle of a packet, please refer to the Logical_Flow table in ovn-sb(5). This section mentions several data and metadata fields, for clarity summarized here: tunnel key When OVN encapsulates a packet in Geneve or another tun‐ nel, it attaches extra data to it to allow the receiving OVN instance to process it correctly. This takes differ‐ ent forms depending on the particular encapsulation, but in each case we refer to it here as the ``tunnel key.’’ See Tunnel Encapsulations, below, for details. logical datapath field A field that denotes the logical datapath through which a packet is being processed. OVN uses the field that Open‐ Flow 1.1+ simply (and confusingly) calls ``metadata’’ to store the logical datapath. (This field is passed across tunnels as part of the tunnel key.) logical input port field A field that denotes the logical port from which the packet entered the logical datapath. OVN stores this in Open vSwitch extension register number 14. Geneve and STT tunnels pass this field as part of the tunnel key. Although VXLAN tunnels do not explicitly carry a logical input port, OVN only uses VXLAN to commu‐ nicate with gateways that from OVN’s perspective consist of only a single logical port, so that OVN can set the logical input port field to this one on ingress to the OVN logical pipeline. logical output port field A field that denotes the logical port from which the packet will leave the logical datapath. This is initial‐ ized to 0 at the beginning of the logical ingress pipe‐ line. OVN stores this in Open vSwitch extension register number 15. Geneve and STT tunnels pass this field as part of the tunnel key. VXLAN tunnels do not transmit the logical output port field. Since VXLAN tunnels do not carry a logical output port field in the tunnel key, when a packet is received from VXLAN tunnel by an OVN hypervi‐ sor, the packet is resubmitted to table 8 to determine the output port(s); when the packet reaches table 32, these packets are resubmitted to table 33 for local de‐ livery by checking a MLF_RCV_FROM_VXLAN flag, which is set when the packet arrives from a VXLAN tunnel. conntrack zone field for logical ports A field that denotes the connection tracking zone for logical ports. The value only has local significance and is not meaningful between chassis. This is initialized to 0 at the beginning of the logical ingress pipeline. OVN stores this in Open vSwitch extension register number 13. conntrack zone fields for routers Fields that denote the connection tracking zones for routers. These values only have local significance and are not meaningful between chassis. OVN stores the zone information for DNATting in Open vSwitch extension regis‐ ter number 11 and zone information for SNATing in Open vSwitch extension register number 12. logical flow flags The logical flags are intended to handle keeping context between tables in order to decide which rules in subse‐ quent tables are matched. These values only have local significance and are not meaningful between chassis. OVN stores the logical flags in Open vSwitch extension regis‐ ter number 10. VLAN ID The VLAN ID is used as an interface between OVN and con‐ tainers nested inside a VM (see Life Cycle of a container interface inside a VM, above, for more information). Initially, a VM or container on the ingress hypervisor sends a packet on a port attached to the OVN integration bridge. Then: 1. OpenFlow table 0 performs physical-to-logical translation. It matches the packet’s ingress port. Its actions annotate the packet with logical metadata, by setting the logical datapath field to identify the logical datapath that the packet is traversing and the logical input port field to identify the ingress port. Then it resubmits to table 8 to enter the logical ingress pipeline. Packets that originate from a container nested within a VM are treated in a slightly different way. The originating container can be distinguished based on the VIF-specific VLAN ID, so the physical-to-logical translation flows addi‐ tionally match on VLAN ID and the actions strip the VLAN header. Following this step, OVN treats packets from con‐ tainers just like any other packets. Table 0 also processes packets that arrive from other chas‐ sis. It distinguishes them from other packets by ingress port, which is a tunnel. As with packets just entering the OVN pipeline, the actions annotate these packets with logi‐ cal datapath and logical ingress port metadata. In addition, the actions set the logical output port field, which is available because in OVN tunneling occurs after the logical output port is known. These three pieces of information are obtained from the tunnel encapsulation metadata (see Tunnel Encapsulations for encoding details). Then the actions re‐ submit to table 33 to enter the logical egress pipeline. 2. OpenFlow tables 8 through 31 execute the logical ingress pipeline from the Logical_Flow table in the OVN Southbound database. These tables are expressed entirely in terms of logical concepts like logical ports and logical datapaths. A big part of ovn-controller’s job is to translate them into equivalent OpenFlow (in particular it translates the table numbers: Logical_Flow tables 0 through 23 become OpenFlow tables 8 through 31). Each logical flow maps to one or more OpenFlow flows. An ac‐ tual packet ordinarily matches only one of these, although in some cases it can match more than one of these flows (which is not a problem because all of them have the same actions). ovn-controller uses the first 32 bits of the logi‐ cal flow’s UUID as the cookie for its OpenFlow flow or flows. (This is not necessarily unique, since the first 32 bits of a logical flow’s UUID is not necessarily unique.) Some logical flows can map to the Open vSwitch ``conjunctive match’’ extension (see ovs-fields(7)). Flows with a conjunc‐ tion action use an OpenFlow cookie of 0, because they can correspond to multiple logical flows. The OpenFlow flow for a conjunctive match includes a match on conj_id. Some logical flows may not be represented in the OpenFlow tables on a given hypervisor, if they could not be used on that hypervisor. For example, if no VIF in a logical switch resides on a given hypervisor, and the logical switch is not otherwise reachable on that hypervisor (e.g. over a series of hops through logical switches and routers starting from a VIF on the hypervisor), then the logical flow may not be represented there. Most OVN actions have fairly obvious implementations in OpenFlow (with OVS extensions), e.g. next; is implemented as resubmit, field = constant; as set_field. A few are worth describing in more detail: output: Implemented by resubmitting the packet to table 32. If the pipeline executes more than one output action, then each one is separately resubmitted to table 32. This can be used to send multiple copies of the packet to multiple ports. (If the packet was not mod‐ ified between the output actions, and some of the copies are destined to the same hypervisor, then us‐ ing a logical multicast output port would save band‐ width between hypervisors.) get_arp(P, A); get_nd(P, A); Implemented by storing arguments into OpenFlow fields, then resubmitting to table 66, which ovn-controller populates with flows generated from the MAC_Binding ta‐ ble in the OVN Southbound database. If there is a match in table 66, then its actions store the bound MAC in the Ethernet destination address field. (The OpenFlow actions save and restore the OpenFlow fields used for the arguments, so that the OVN actions do not have to be aware of this temporary use.) put_arp(P, A, E); put_nd(P, A, E); Implemented by storing the arguments into OpenFlow fields, then outputting a packet to ovn-controller, which updates the MAC_Binding table. (The OpenFlow actions save and restore the OpenFlow fields used for the arguments, so that the OVN actions do not have to be aware of this temporary use.) 3. OpenFlow tables 32 through 47 implement the output action in the logical ingress pipeline. Specifically, table 32 handles packets to remote hypervisors, table 33 handles packets to the local hypervisor, and table 34 checks whether packets whose logical ingress and egress port are the same should be discarded. Logical patch ports are a special case. Logical patch ports do not have a physical location and effectively reside on every hypervisor. Thus, flow table 33, for output to ports on the local hypervisor, naturally implements output to uni‐ cast logical patch ports too. However, applying the same logic to a logical patch port that is part of a logical mul‐ ticast group yields packet duplication, because each hyper‐ visor that contains a logical port in the multicast group will also output the packet to the logical patch port. Thus, multicast groups implement output to logical patch ports in table 32. Each flow in table 32 matches on a logical output port for unicast or multicast logical ports that include a logical port on a remote hypervisor. Each flow’s actions implement sending a packet to the port it matches. For unicast logical output ports on remote hypervisors, the actions set the tun‐ nel key to the correct value, then send the packet on the tunnel port to the correct hypervisor. (When the remote hy‐ pervisor receives the packet, table 0 there will recognize it as a tunneled packet and pass it along to table 33.) For multicast logical output ports, the actions send one copy of the packet to each remote hypervisor, in the same way as for unicast destinations. If a multicast group includes a logi‐ cal port or ports on the local hypervisor, then its actions also resubmit to table 33. Table 32 also includes: • A higher-priority rule to match packets received from VXLAN tunnels, based on flag MLF_RCV_FROM_VXLAN, and resubmit these packets to table 33 for local deliv‐ ery. Packets received from VXLAN tunnels reach here because of a lack of logical output port field in the tunnel key and thus these packets needed to be sub‐ mitted to table 8 to determine the output port. • A higher-priority rule to match packets received from ports of type localport, based on the logical input port, and resubmit these packets to table 33 for lo‐ cal delivery. Ports of type localport exist on every hypervisor and by definition their traffic should never go out through a tunnel. • A higher-priority rule to match packets that have the MLF_LOCAL_ONLY logical flow flag set, and whose des‐ tination is a multicast address. This flag indicates that the packet should not be delivered to remote hy‐ pervisors, even if the multicast destination includes ports on remote hypervisors. This flag is used when ovn-controller is the originator of the multicast packet. Since each ovn-controller instance is origi‐ nating these packets, the packets only need to be de‐ livered to local ports. • A fallback flow that resubmits to table 33 if there is no other match. Flows in table 33 resemble those in table 32 but for logical ports that reside locally rather than remotely. For unicast logical output ports on the local hypervisor, the actions just resubmit to table 34. For multicast output ports that include one or more logical ports on the local hypervisor, for each such logical port P, the actions change the logical output port to P, then resubmit to table 34. A special case is that when a localnet port exists on the datapath, remote port is connected by switching to the lo‐ calnet port. In this case, instead of adding a flow in table 32 to reach the remote port, a flow is added in table 33 to switch the logical outport to the localnet port, and resub‐ mit to table 33 as if it were unicasted to a logical port on the local hypervisor. Table 34 matches and drops packets for which the logical in‐ put and output ports are the same and the MLF_ALLOW_LOOPBACK flag is not set. It resubmits other packets to table 40. 4. OpenFlow tables 40 through 63 execute the logical egress pipeline from the Logical_Flow table in the OVN Southbound database. The egress pipeline can perform a final stage of validation before packet delivery. Eventually, it may exe‐ cute an output action, which ovn-controller implements by resubmitting to table 64. A packet for which the pipeline never executes output is effectively dropped (although it may have been transmitted through a tunnel across a physical network). The egress pipeline cannot change the logical output port or cause further tunneling. 5. Table 64 bypasses OpenFlow loopback when MLF_ALLOW_LOOPBACK is set. Logical loopback was handled in table 34, but Open‐ Flow by default also prevents loopback to the OpenFlow ingress port. Thus, when MLF_ALLOW_LOOPBACK is set, OpenFlow table 64 saves the OpenFlow ingress port, sets it to zero, resubmits to table 65 for logical-to-physical transforma‐ tion, and then restores the OpenFlow ingress port, effec‐ tively disabling OpenFlow loopback prevents. When MLF_AL‐ LOW_LOOPBACK is unset, table 64 flow simply resubmits to ta‐ ble 65. 6. OpenFlow table 65 performs logical-to-physical translation, the opposite of table 0. It matches the packet’s logical egress port. Its actions output the packet to the port at‐ tached to the OVN integration bridge that represents that logical port. If the logical egress port is a container nested with a VM, then before sending the packet the actions push on a VLAN header with an appropriate VLAN ID. Logical Routers and Logical Patch Ports Typically logical routers and logical patch ports do not have a physi‐ cal location and effectively reside on every hypervisor. This is the case for logical patch ports between logical routers and logical switches behind those logical routers, to which VMs (and VIFs) attach. Consider a packet sent from one virtual machine or container to another VM or container that resides on a different subnet. The packet will traverse tables 0 to 65 as described in the previous section Architec‐ tural Physical Life Cycle of a Packet, using the logical datapath rep‐ resenting the logical switch that the sender is attached to. At table 32, the packet will use the fallback flow that resubmits locally to ta‐ ble 33 on the same hypervisor. In this case, all of the processing from table 0 to table 65 occurs on the hypervisor where the sender resides. When the packet reaches table 65, the logical egress port is a logical patch port. The implementation in table 65 differs depending on the OVS version, although the observed behavior is meant to be the same: • In OVS versions 2.6 and earlier, table 65 outputs to an OVS patch port that represents the logical patch port. The packet re-enters the OpenFlow flow table from the OVS patch port’s peer in table 0, which identifies the logi‐ cal datapath and logical input port based on the OVS patch port’s OpenFlow port number. • In OVS versions 2.7 and later, the packet is cloned and resubmitted directly to the first OpenFlow flow table in the ingress pipeline, setting the logical ingress port to the peer logical patch port, and using the peer logical patch port’s logical datapath (that represents the logi‐ cal router). The packet re-enters the ingress pipeline in order to traverse tables 8 to 65 again, this time using the logical datapath representing the log‐ ical router. The processing continues as described in the previous sec‐ tion Architectural Physical Life Cycle of a Packet. When the packet reachs table 65, the logical egress port will once again be a logical patch port. In the same manner as described above, this logical patch port will cause the packet to be resubmitted to OpenFlow tables 8 to 65, this time using the logical datapath representing the logical switch that the destination VM or container is attached to. The packet traverses tables 8 to 65 a third and final time. If the des‐ tination VM or container resides on a remote hypervisor, then table 32 will send the packet on a tunnel port from the sender’s hypervisor to the remote hypervisor. Finally table 65 will output the packet directly to the destination VM or container. The following sections describe two exceptions, where logical routers and/or logical patch ports are associated with a physical location. Gateway Routers A gateway router is a logical router that is bound to a physical loca‐ tion. This includes all of the logical patch ports of the logical router, as well as all of the peer logical patch ports on logical switches. In the OVN Southbound database, the Port_Binding entries for these logical patch ports use the type l3gateway rather than patch, in order to distinguish that these logical patch ports are bound to a chassis. When a hypervisor processes a packet on a logical datapath representing a logical switch, and the logical egress port is a l3gateway port rep‐ resenting connectivity to a gateway router, the packet will match a flow in table 32 that sends the packet on a tunnel port to the chassis where the gateway router resides. This processing in table 32 is done in the same manner as for VIFs. Gateway routers are typically used in between distributed logical routers and physical networks. The distributed logical router and the logical switches behind it, to which VMs and containers attach, effec‐ tively reside on each hypervisor. The distributed router and the gate‐ way router are connected by another logical switch, sometimes referred to as a join logical switch. On the other side, the gateway router con‐ nects to another logical switch that has a localnet port connecting to the physical network. When using gateway routers, DNAT and SNAT rules are associated with the gateway router, which provides a central location that can handle one- to-many SNAT (aka IP masquerading). Distributed Gateway Ports Distributed gateway ports are logical router patch ports that directly connect distributed logical routers to logical switches with localnet ports. The primary design goal of distributed gateway ports is to allow as much traffic as possible to be handled locally on the hypervisor where a VM or container resides. Whenever possible, packets from the VM or container to the outside world should be processed completely on that VM’s or container’s hypervisor, eventually traversing a localnet port instance on that hypervisor to the physical network. Whenever possible, packets from the outside world to a VM or container should be directed through the physical network directly to the VM’s or container’s hyper‐ visor, where the packet will enter the integration bridge through a lo‐ calnet port. In order to allow for the distributed processing of packets described in the paragraph above, distributed gateway ports need to be logical patch ports that effectively reside on every hypervisor, rather than l3gateway ports that are bound to a particular chassis. However, the flows associated with distributed gateway ports often need to be asso‐ ciated with physical locations, for the following reasons: • The physical network that the localnet port is attached to typically uses L2 learning. Any Ethernet address used over the distributed gateway port must be restricted to a single physical location so that upstream L2 learning is not confused. Traffic sent out the distributed gateway port towards the localnet port with a specific Ethernet address must be sent out one specific instance of the distributed gateway port on one specific chassis. Traffic received from the localnet port (or from a VIF on the same logical switch as the localnet port) with a specific Ethernet address must be directed to the logical switch’s patch port instance on that specific chassis. Due to the implications of L2 learning, the Ethernet ad‐ dress and IP address of the distributed gateway port need to be restricted to a single physical location. For this reason, the user must specify one chassis associated with the distributed gateway port. Note that traffic travers‐ ing the distributed gateway port using other Ethernet ad‐ dresses and IP addresses (e.g. one-to-one NAT) is not re‐ stricted to this chassis. Replies to ARP and ND requests must be restricted to a single physical location, where the Ethernet address in the reply resides. This includes ARP and ND replies for the IP address of the distributed gateway port, which are restricted to the chassis that the user associated with the distributed gateway port. • In order to support one-to-many SNAT (aka IP masquerad‐ ing), where multiple logical IP addresses spread across multiple chassis are mapped to a single external IP ad‐ dress, it will be necessary to handle some of the logical router processing on a specific chassis in a centralized manner. Since the SNAT external IP address is typically the distributed gateway port IP address, and for simplic‐ ity, the same chassis associated with the distributed gateway port is used. The details of flow restrictions to specific chassis are described in the ovn-northd documentation. While most of the physical location dependent aspects of distributed gateway ports can be handled by restricting some flows to specific chassis, one additional mechanism is required. When a packet leaves the ingress pipeline and the logical egress port is the distributed gateway port, one of two different sets of actions is required at table 32: • If the packet can be handled locally on the sender’s hy‐ pervisor (e.g. one-to-one NAT traffic), then the packet should just be resubmitted locally to table 33, in the normal manner for distributed logical patch ports. • However, if the packet needs to be handled on the chassis associated with the distributed gateway port (e.g. one- to-many SNAT traffic or non-NAT traffic), then table 32 must send the packet on a tunnel port to that chassis. In order to trigger the second set of actions, the chassisredirect type of southbound Port_Binding has been added. Setting the logical egress port to the type chassisredirect logical port is simply a way to indi‐ cate that although the packet is destined for the distributed gateway port, it needs to be redirected to a different chassis. At table 32, packets with this logical egress port are sent to a specific chassis, in the same way that table 32 directs packets whose logical egress port is a VIF or a type l3gateway port to different chassis. Once the packet arrives at that chassis, table 33 resets the logical egress port to the value representing the distributed gateway port. For each distributed gateway port, there is one type chassisredirect port, in addition to the distributed logical patch port representing the distributed gateway port. High Availability for Distributed Gateway Ports OVN allows you to specify a prioritized list of chassis for a distrib‐ uted gateway port. This is done by associating multiple Gateway_Chassis rows with a Logical_Router_Port in the OVN_Northbound database. When multiple chassis have been specified for a gateway, all chassis that may send packets to that gateway will enable BFD on tunnels to all configured gateway chassis. The current master chassis for the gateway is the highest priority gateway chassis that is currently viewed as ac‐ tive based on BFD status. For more information on L3 gateway high availability, please refer to http://docs.openvswitch.org/en/latest/topics/high-availability. Multiple localnet logical switches connected to a Logical Router It is possible to have multiple logical switches each with a localnet port (representing physical networks) connected to a logical router, in which one localnet logical switch may provide the external connectivity via a distributed gateway port and rest of the localnet logical switches use VLAN tagging in the physical network. It is expected that ovn-bridge-mappings is configured appropriately on the chassis for all these localnet networks. East West routing East-West routing between these localnet VLAN tagged logical switches work almost the same way as normal logical switches. When the VM sends such a packet, then: 1. It first enters the ingress pipeline, and then egress pipe‐ line of the source localnet logical switch datapath. It then enters the ingress pipeline of the logical router datapath via the logical router port in the source chassis. 2. Routing decision is taken. 3. From the router datapath, packet enters the ingress pipeline and then egress pipeline of the destination localnet logical switch datapath and goes out of the integration bridge to the provider bridge ( belonging to the destination logical switch) via the localnet port. 4. The destination chassis receives the packet via the localnet port and sends it to the integration bridge. The packet en‐ ters the ingress pipeline and then egress pipeline of the destination localnet logical switch and finally gets deliv‐ ered to the destination VM port. External traffic The following happens when a VM sends an external traffic (which re‐ quires NATting) and the chassis hosting the VM doesn’t have a distrib‐ uted gateway port. 1. The packet first enters the ingress pipeline, and then egress pipeline of the source localnet logical switch data‐ path. It then enters the ingress pipeline of the logical router datapath via the logical router port in the source chassis. 2. Routing decision is taken. Since the gateway router or the distributed gateway port doesn’t reside in the source chas‐ sis, the traffic is redirected to the gateway chassis via the tunnel port. 3. The gateway chassis receives the packet via the tunnel port and the packet enters the egress pipeline of the logical router datapath. NAT rules are applied here. The packet then enters the ingress pipeline and then egress pipeline of the localnet logical switch datapath which provides external connectivity and finally goes out via the localnet port of the logical switch which provides external connectivity. Although this works, the VM traffic is tunnelled when sent from the compute chassis to the gateway chassis. In order for it to work prop‐ erly, the MTU of the localnet logical switches must be lowered to ac‐ count for the tunnel encapsulation. Centralized routing for localnet VLAN tagged logical switches connected to a Logical Router " To overcome the tunnel encapsulation problem described in the previous section, OVN supports the option of enabling centralized routing for localnet VLAN tagged logical switches. CMS can configure the option op‐ tions:reside-on-redirect-chassis to true for each Logical_Router_Port which connects to the localnet VLAN tagged logical switches. This causes the gateway chassis (hosting the distributed gateway port) to handle all the routing for these networks, making it centralized. It will reply to the ARP requests for the logical router port IPs. If the logical router doesn’t have a distributed gateway port connect‐ ing to the localnet logical switch which provides external connectiv‐ ity, then this option is ignored by OVN. The following happens when a VM sends an east-west traffic which needs to be routed: 1. The packet first enters the ingress pipeline, and then egress pipeline of the source localnet logical switch data‐ path and is sent out via the localnet port of the source lo‐ calnet logical switch (instead of sending it to router pipe‐ line). 2. The gateway chassis receives the packet via the localnet port of the source localnet logical switch and sends it to the integration bridge. The packet then enters the ingress pipeline, and then egress pipeline of the source localnet logical switch datapath and enters the ingress pipeline of the logical router datapath. 3. Routing decision is taken. 4. From the router datapath, packet enters the ingress pipeline and then egress pipeline of the destination localnet logical switch datapath. It then goes out of the integration bridge to the provider bridge ( belonging to the destination logi‐ cal switch) via the localnet port. 5. The destination chassis receives the packet via the localnet port and sends it to the integration bridge. The packet en‐ ters the ingress pipeline and then egress pipeline of the destination localnet logical switch and finally delivered to the destination VM port. The following happens when a VM sends an external traffic which re‐ quires NATting: 1. The packet first enters the ingress pipeline, and then egress pipeline of the source localnet logical switch data‐ path and is sent out via the localnet port of the source lo‐ calnet logical switch (instead of sending it to router pipe‐ line). 2. The gateway chassis receives the packet via the localnet port of the source localnet logical switch and sends it to the integration bridge. The packet then enters the ingress pipeline, and then egress pipeline of the source localnet logical switch datapath and enters the ingress pipeline of the logical router datapath. 3. Routing decision is taken and NAT rules are applied. 4. From the router datapath, packet enters the ingress pipeline and then egress pipeline of the localnet logical switch datapath which provides external connectivity. It then goes out of the integration bridge to the provider bridge (be‐ longing to the logical switch which provides external con‐ nectivity) via the localnet port. The following happens for the reverse external traffic. 1. The gateway chassis receives the packet from the localnet port of the logical switch which provides external connec‐ tivity. The packet then enters the ingress pipeline and then egress pipeline of the localnet logical switch (which pro‐ vides external connectivity). The packet then enters the ingress pipeline of the logical router datapath. 2. The ingress pipeline of the logical router datapath applies the unNATting rules. The packet then enters the ingress pipeline and then egress pipeline of the source localnet logical switch. Since the source VM doesn’t reside in the gateway chassis, the packet is sent out via the localnet port of the source logical switch. 3. The source chassis receives the packet via the localnet port and sends it to the integration bridge. The packet enters the ingress pipeline and then egress pipeline of the source localnet logical switch and finally gets delivered to the source VM port. Life Cycle of a VTEP gateway A gateway is a chassis that forwards traffic between the OVN-managed part of a logical network and a physical VLAN, extending a tunnel-based logical network into a physical network. The steps below refer often to details of the OVN and VTEP database schemas. Please see ovn-sb(5), ovn-nb(5) and vtep(5), respectively, for the full story on these databases. 1. A VTEP gateway’s life cycle begins with the administrator registering the VTEP gateway as a Physical_Switch table en‐ try in the VTEP database. The ovn-controller-vtep connected to this VTEP database, will recognize the new VTEP gateway and create a new Chassis table entry for it in the OVN_Southbound database. 2. The administrator can then create a new Logical_Switch table entry, and bind a particular vlan on a VTEP gateway’s port to any VTEP logical switch. Once a VTEP logical switch is bound to a VTEP gateway, the ovn-controller-vtep will detect it and add its name to the vtep_logical_switches column of the Chassis table in the OVN_Southbound database. Note, the tunnel_key column of VTEP logical switch is not filled at creation. The ovn-controller-vtep will set the column when the correponding vtep logical switch is bound to an OVN log‐ ical network. 3. Now, the administrator can use the CMS to add a VTEP logical switch to the OVN logical network. To do that, the CMS must first create a new Logical_Switch_Port table entry in the OVN_Northbound database. Then, the type column of this entry must be set to "vtep". Next, the vtep-logical-switch and vtep-physical-switch keys in the options column must also be specified, since multiple VTEP gateways can attach to the same VTEP logical switch. 4. The newly created logical port in the OVN_Northbound data‐ base and its configuration will be passed down to the OVN_Southbound database as a new Port_Binding table entry. The ovn-controller-vtep will recognize the change and bind the logical port to the corresponding VTEP gateway chassis. Configuration of binding the same VTEP logical switch to a different OVN logical networks is not allowed and a warning will be generated in the log. 5. Beside binding to the VTEP gateway chassis, the ovn-con‐ troller-vtep will update the tunnel_key column of the VTEP logical switch to the corresponding Datapath_Binding table entry’s tunnel_key for the bound OVN logical network. 6. Next, the ovn-controller-vtep will keep reacting to the con‐ figuration change in the Port_Binding in the OVN_Northbound database, and updating the Ucast_Macs_Remote table in the VTEP database. This allows the VTEP gateway to understand where to forward the unicast traffic coming from the ex‐ tended external network. 7. Eventually, the VTEP gateway’s life cycle ends when the ad‐ ministrator unregisters the VTEP gateway from the VTEP data‐ base. The ovn-controller-vtep will recognize the event and remove all related configurations (Chassis table entry and port bindings) in the OVN_Southbound database. 8. When the ovn-controller-vtep is terminated, all related con‐ figurations in the OVN_Southbound database and the VTEP database will be cleaned, including Chassis table entries for all registered VTEP gateways and their port bindings, and all Ucast_Macs_Remote table entries and the Logi‐ cal_Switch tunnel keys. SECURITY Role-Based Access Controls for the Soutbound DB In order to provide additional security against the possibility of an OVN chassis becoming compromised in such a way as to allow rogue soft‐ ware to make arbitrary modifications to the southbound database state and thus disrupt the OVN network, role-based access controls (see ovsdb-server(1) for additional details) are provided for the southbound database. The implementation of role-based access controls (RBAC) requires the addition of two tables to an OVSDB schema: the RBAC_Role table, which is indexed by role name and maps the the names of the various tables that may be modifiable for a given role to individual rows in a permis‐ sions table containing detailed permission information for that role, and the permission table itself which consists of rows containing the following information: Table Name The name of the associated table. This column exists pri‐ marily as an aid for humans reading the contents of this table. Auth Criteria A set of strings containing the names of columns (or col‐ umn:key pairs for columns containing string:string maps). The contents of at least one of the columns or column:key values in a row to be modified, inserted, or deleted must be equal to the ID of the client attempting to act on the row in order for the authorization check to pass. If the authorization criteria is empty, authorization checking is disabled and all clients for the role will be treated as authorized. Insert/Delete Row insertion/deletion permission; boolean value indicat‐ ing whether insertion and deletion of rows is allowed for the associated table. If true, insertion and deletion of rows is allowed for authorized clients. Updatable Columns A set of strings containing the names of columns or col‐ umn:key pairs that may be updated or mutated by autho‐ rized clients. Modifications to columns within a row are only permitted when the authorization check for the client passes and all columns to be modified are included in this set of modifiable columns. RBAC configuration for the OVN southbound database is maintained by ovn-northd. With RBAC enabled, modifications are only permitted for the Chassis, Encap, Port_Binding, and MAC_Binding tables, and are resstricted as follows: Chassis Authorization: client ID must match the chassis name. Insert/Delete: authorized row insertion and deletion are permitted. Update: The columns nb_cfg, external_ids, encaps, and vtep_logical_switches may be modified when authorized. Encap Authorization: client ID must match the chassis name. Insert/Delete: row insertion and row deletion are permit‐ ted. Update: The columns type, options, and ip can be modi‐ fied. Port_Binding Authorization: disabled (all clients are considered au‐ thorized. A future enhancement may add columns (or keys to external_ids) in order to control which chassis are allowed to bind each port. Insert/Delete: row insertion/deletion are not permitted (ovn-northd maintains rows in this table. Update: Only modifications to the chassis column are per‐ mitted. MAC_Binding Authorization: disabled (all clients are considered to be authorized). Insert/Delete: row insertion/deletion are permitted. Update: The columns logical_port, ip, mac, and datapath may be modified by ovn-controller. Enabling RBAC for ovn-controller connections to the southbound database requires the following steps: 1. Creating SSL certificates for each chassis with the certifi‐ cate CN field set to the chassis name (e.g. for a chassis with external-ids:system-id=chassis-1, via the command "ovs-pki -u req+sign chassis-1 switch"). 2. Configuring each ovn-controller to use SSL when connecting to the southbound database (e.g. via "ovs-vsctl set open . external-ids:ovn-remote=ssl:x.x.x.x:6642"). 3. Configuring a southbound database SSL remote with "ovn-con‐ troller" role (e.g. via "ovn-sbctl set-connection role=ovn-controller pssl:6642"). Encrypt Tunnel Traffic with IPsec OVN tunnel traffic goes through physical routers and switches. These physical devices could be untrusted (devices in public network) or might be compromised. Enabling encryption to the tunnel traffic can prevent the traffic data from being monitored and manipulated. The tunnel traffic is encrypted with IPsec. The CMS sets the ipsec col‐ umn in the northbound NB_Global table to enable or disable IPsec encry‐ tion. If ipsec is true, all OVN tunnels will be encrypted. If ipsec is false, no OVN tunnels will be encrypted. When CMS updates the ipsec column in the northbound NB_Global table, ovn-northd copies the value to the ipsec column in the southbound SB_Global table. ovn-controller in each chassis monitors the southbound database and sets the options of the OVS tunnel interface accordingly. OVS tunnel interface options are monitored by the ovs-monitor-ipsec daemon which configures IKE daemon to set up IPsec connections. Chassis authenticates each other by using certificate. The authentica‐ tion succeeds if the other end in tunnel presents a certificate signed by a trusted CA and the common name (CN) matches the expected chassis name. The SSL certificates used in role-based access controls (RBAC) can be used in IPsec. Or use ovs-pki to create different certificates. The certificate is required to be x.509 version 3, and with CN field and subjectAltName field being set to the chassis name. The CA certificate, chassis certificate and private key are required to be installed in each chassis before enabling IPsec. Please see ovs-vswitchd.conf.db(5) for setting up CA based IPsec authentication. DESIGN DECISIONS Tunnel Encapsulations OVN annotates logical network packets that it sends from one hypervisor to another with the following three pieces of metadata, which are en‐ coded in an encapsulation-specific fashion: • 24-bit logical datapath identifier, from the tunnel_key column in the OVN Southbound Datapath_Binding table. • 15-bit logical ingress port identifier. ID 0 is reserved for internal use within OVN. IDs 1 through 32767, inclu‐ sive, may be assigned to logical ports (see the tun‐ nel_key column in the OVN Southbound Port_Binding table). • 16-bit logical egress port identifier. IDs 0 through 32767 have the same meaning as for logical ingress ports. IDs 32768 through 65535, inclusive, may be assigned to logical multicast groups (see the tunnel_key column in the OVN Southbound Multicast_Group table). For hypervisor-to-hypervisor traffic, OVN supports only Geneve and STT encapsulations, for the following reasons: • Only STT and Geneve support the large amounts of metadata (over 32 bits per packet) that OVN uses (as described above). • STT and Geneve use randomized UDP or TCP source ports that allows efficient distribution among multiple paths in environments that use ECMP in their underlay. • NICs are available to offload STT and Geneve encapsula‐ tion and decapsulation. Due to its flexibility, the preferred encapsulation between hypervisors is Geneve. For Geneve encapsulation, OVN transmits the logical datapath identifier in the Geneve VNI. OVN transmits the logical ingress and logical egress ports in a TLV with class 0x0102, type 0x80, and a 32-bit value encoded as follows, from MSB to LSB: 1 15 16 +---+------------+-----------+ |rsv|ingress port|egress port| +---+------------+-----------+ 0 Environments whose NICs lack Geneve offload may prefer STT encapsula‐ tion for performance reasons. For STT encapsulation, OVN encodes all three pieces of logical metadata in the STT 64-bit tunnel ID as fol‐ lows, from MSB to LSB: 9 15 16 24 +--------+------------+-----------+--------+ |reserved|ingress port|egress port|datapath| +--------+------------+-----------+--------+ 0 For connecting to gateways, in addition to Geneve and STT, OVN supports VXLAN, because only VXLAN support is common on top-of-rack (ToR) switches. Currently, gateways have a feature set that matches the capa‐ bilities as defined by the VTEP schema, so fewer bits of metadata are necessary. In the future, gateways that do not support encapsulations with large amounts of metadata may continue to have a reduced feature set. Open vSwitch 2.10.90 OVN Architecture ovn-architecture(7)


{% extends "modal.html" %} {% block content %} {% if account %}
Your account {{ user.username }} has been activated.
Click here to login
Please contact<EMAIL_ADDRESS>for assistance.
Click here to return to the site


Work
Contact
Hello, I'm Mylene
Web developer
in training
Work
Product Landing Page
Tribute Page
Technical Documentation
Let's work together...
CodePen
GitHub
Linkedin
FreeCodeCamp
Twitter


Hello! I'm founder, owner, and programmer of TPL. I develop many kinds of things and leads our team!
No Introduction of JH Kim
© Copyright Top Programming Lab. All Rights Reserved.


Tablesafter taking accessibility into consideration
Last Weeks's Survey Results
What is your favorite and least favorite organ?
|
Lung |
Pancreas |
Spleen |
Liver |
Skin |
Brain |
| hate it |
4 |
10 |
4 |
0 |
1 |
0 |
| love it |
5 |
6 |
0 |
14 |
1 |
0 |
Because of some inconsistencies with how JAWS handles complex tables, some ARIA attributes have to be added to ensure that this kind of table is read consistently across screenreaders and browsers.
Table 2: - Two-year financial Information - with IDs and headers plus aria spans and roles
| Category |
2017 |
2018 |
| |
1st Quarter |
2nd Quarter |
3rd Quarter |
4th Quarter |
1st Quarter |
2nd Quarter |
3rd Quarter |
4th Quarter |
| Expenses |
$100,000 |
$125,000 |
$85,000 |
$50,000 |
$75,000 |
$85,000 |
$90,000 |
$45,000 |
| Income |
150,000 |
150,000 |
100,000 |
$100,000 |
$50,000 |
$100,000 |
$75,000 |
150,000 |