Russian food
Russian cuisine is a collection of the different cooking traditions of the Russian people. The cuisine is diverse, with Northern and Eastern European, Caucasian, Central Asian, Siberian, and East Asian influences. Russian cuisine derives its varied character from the vast and multi-ethnic expanse of Russia. Its foundations were laid by the peasant food of the rural population in an often harsh climate, with a combination of plentiful fish, pork, poultry, caviar, mushrooms, berries, and honey. Crops of rye, wheat, barley and millet provided the ingredients for a plethora of breads, pancakes, pies, cereals, beer and vodka. Soups and stews are centered on seasonal or storable produce, fish and meats. Such food remained the staple for the vast majority of Russians well into the 20th century. Soviet cuisine had a separate character of its own.


Welcome!
This site demonstrates the power, flexibility, and scalability of a 32-bit embedded web server. Everything you see is powered by a SAMRH71 Microchip microcontroller.
On the right you'll see the current status of the demo board. For a quick example, click the LEDs to toggle the lights on the board. Press the push buttons (except MCLR!) and you'll see the status update immediately. This examples uses AJAX techniques to provide real-time feedback.
SAMV71 motor control :
Target Speed :0
Measured speed :0
Potentiometer :0
Modify Motor command :
Speed :
SAMRH71 :
Buttons states :
•
•
•
LEDs [0..3] command:(click to toggle)
ATmega64M1 motor control :
Target Speed : 0
Measured speed : 0
Direction : 0
Potentiometer : 0
Modify Motor command :
Speed :
Direction :
Direction :
ATmega64M1 sensor :
Buttons states:
•
•
•
•
•
•
•
•
LEDs [7..0]: command:(click to toggle)


{% for image in page.images %}
{% endfor %}
--- layout: home images: - image_path: /assets/img/home/00.jpg - image_path: /assets/img/home/01.jpg - image_path: /assets/img/home/02.jpg - image_path: /assets/img/home/03.jpg - image_path: /assets/img/home/04.jpg - image_path: /assets/img/home/05.jpg - image_path: /assets/img/home/06.jpg - image_path: /assets/img/home/07.jpg - image_path: /assets/img/home/08.jpg - image_path: /assets/img/home/09.jpg ---


You have probably played some version of this game before: one player thinks of a person, an animal, or something else, and another one tries to guess what it is based on the answers. In this project, we will create a similar text game where a computer tries to guess an animal that the user has thought of. One of the first versions of this game was written by Arthur Luehrmann at Dartmouth College in the 1960s.
In the first stage, we will implement greetings and goodbyes, as well as the formation of a question based on the name of the animal.
The computer should greet the user based on the time of the day. “Good morning” should be used from 5:00 am to 12:00 pm, “Good afternoon” is best for the period between 12:00 pm and 6:00 pm, and “Good evening” is used after 6 p.m. You can also get creative and use “Hi, Night Owl” for late night or “Hi, Early Bird” for early morning.
After greeting the user, the program should ask for an animal. The animal should be entered in the following format: a/an + name of the animal, for example, “an elephant”. The user may or may not specify the article. If the user specifies the undefined article it should be kept as is. Otherwise, the program should determine it according to the rules. For simplicity, let's assume that all words beginning with a vowel take the article "an", and those that begin with a consonant take the article "a". The defined article should be replaced by undefined.
Here are examples:
cat => a cat
a cat => a cat
the cat => a cat
ape => an ape
an ape => an ape
the ape => an ape
an elephant => an elephant
a unicorn => a unicorn
a xantic sargo => a xantic sargo
an xeme => an xeme
After entering the name of the animal, the program should formulate the question "Is it a/an <animal>?"
. The question must use the article specified by the user or determined by the program.
Then, the user should answer this question. The computer must perceive these responses as positive: y, yes, yeah, yep, sure, right, affirmative, correct, indeed, you bet, exactly, you said it. The negative answer could be: n, no, no way, nah, nope, negative, I don't think so, yeah no. The letters can be in any case and there can be a period or an exclamation mark at the end of the statement. In case the user's answer is not clear, the program should ask the user to clarify.
With the clarification question, you don't have to stick to one formal phrase. We are creating a game, so let your fantasy fly! Make the computer ask again in a different way each time. The only condition is that the phrase should contain "yes or no". Check out some example phrases below, but you are free to invent your own phrases:
"I'm not sure I caught you: was it yes or no?"
"Funny, I still don't understand, is it yes or no?"
"Oh, it's too complicated for me: just tell me yes or no."
"Could you please simply say yes or no?
"Oh, no, don't try to confuse me: say yes or no."
After accepting the answer, the program should say goodbye to the user. To make our program more lively, let there be several ways to do it. If you need some examples of cool goodbye phrases, watch a Youtube video 33 ways to say "Bye"
The greater-than symbol followed by a space >
represents the user input. Note that it's not part of the input.
Example 1
Good morning!
Enter an animal:
> cat
Is it a cat?
> Yeah
You answered: Yes
Have a nice day!
Example 2
Good afternoon!
Enter an animal:
> unicorn
Is it an unicorn?
> Oops..
Come on, yes or no?
> Nope
You answered: No
See you soon!
Example 3
Good evening!
Enter an animal:
> a unicorn
Is it a unicorn?
> Sure!
You answered: Yes
Bye!


Limited Interaction¶
import limitedinteraction as li
li.button_dialog("Simple dialog windows for scripters and scientists.",
choices=['OK'],
title='Limited Interaction',
icon='light')
This python module provides simple, generic dialog windows specifically aimed to scripters and scientists who need a concise, elegant way of interacting with their script users.
This module does not require any GUI programming, it has no external dependency, and it is completely independent of the graphical backend in use (if any). In IPython-based environments, its blocking functions allow interacting with Matplotlib figures while waiting for user action.
For those transitionning from Matlab, this module fulfils the same role as Matlab’s msgbox, inputdlg, menu and other simple GUI functions.
Home page GitHub Issue tracker API
Installing¶
Using pip:
pip install limitedinteraction
Using conda:
conda install -c conda-forge limitedinteraction
Usage¶
Importing¶
import limitedinteraction as li
Creating a persistent message window¶
li.message('Please wait a few moments.',
title='Calculating...',
icon='clock')
This is a non-blocking function. Any code after this call is executed immediately, while this message window stays in foreground. To close the message window:
li.message('')
Asking for user input¶
name = li.input_dialog('What is your name?', icon='question')
This is a blocking function. We wait for user input before continuing. Meanwhile, Matplotlib’s event loop is refreshed so that the user can interact with figures.
This same function can have several inputs and some inputs can be masked:
credentials = li.input_dialog('Please enter your credentials',
labels=['Username:', 'Password:'],
initial_values=['username', 'password'],
masked=[False, True],
icon='lock')
choice_index = li.button_dialog('Please zoom on the figure and click Next.',
choices=['Next', 'Cancel'],
title='User interaction',
icon='gear')
This is a blocking function. We wait for a choice before continuing. Meanwhile, Matplotlib’s event loop is refreshed so that the user can interact with figures.
Other functions¶
Get a file name using the operating system’s standard file selection window:
filename = li.get_filename()
Get a folder name using the operating system’s standard folder selection window:
folder = li.get_folder()
Credits¶
This module is developed by Félix Chénier at the Mobility and Adaptive Sports Research Lab (https://felixchenier.uqam.ca).
It includes artwork developed by these designers:
Warning and gear icons: Laura Reen
Question mark icon: Design Revision
All other icons: Recep Kütük


It's Hacking Time.
Rest assured, your personally identifiable data is not being stolen by us, and this site and WiFi network operate purely off of principles that you would find daily as you browse the web with no shady business like IP or location logging, and nothing to do with advertising on this site. If you are interested in how this site and WiFi network function, you are welcome to contact us with the information provided at the bottom of this page. In terms of data collected, we simply log your visit onto this page and how long you stay, for our wonderous statistics page you can find below! If you choose to leave a reaction below, that will also get saved, obviously. No other information (such as background network tasks, etc.) get taken. This site does not use cookies.
No
Personal Information Taken
100%
Anonymized Statistics
0
Cookies Used
Statistics
N/A
People Rick Rolled
N/A
Average Time on Site
N/A
Who Scrolled Down
Refresh Aggregated Stats Visit Stats


Pick your favorite NFL player to see Career and Criminal Stats!!.
Criminal for the NFLArrest.API.
NFL Stats from SportsRadar Api will go here.
NFL videos to display from youtube API


Secret share objects: provides API to perform operations on shares securly, wrap promises
and communication primitives to ensure operations are executed when shares are available (asynchronously)
without requiring the user to perform promise management/synchronization.
- Source:
Members
holders :Array
Type:
- Array
- Source:
id :string
Type:
- string
- Source:
jiff :jiff-instance
Type:
- Source:
promise :promise
Type:
- promise
- Source:
ready :boolean
Type:
- boolean
- Source:
threshold :Array
Type:
- Array
- Source:
value :number
Type:
- number
- Source:
Zp :number
Type:
- number
- Source:
Methods
add(o) → {SecretShare}
Generic Addition.
Uses either the constant or secret version of this operator depending on type of paramter.
Parameters:
| Name | Type | Description |
|---|---|---|
o |
number | SecretShare | the other operand (can be either number or share). |
- Source:
Returns:
this party's share of the result.
- Type
- SecretShare
cadd(cst) → {SecretShare}
Addition with a constant.
Parameters:
| Name | Type | Description |
|---|---|---|
cst |
number | the constant to add. |
- Source:
Returns:
this party's share of the result.
- Type
- SecretShare
cdiv(cst, op_idopt) → {SecretShare}
Integer divison with a share and a constant (self / cst).
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
cst |
SecretShare | the constant to divide by. | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. |
- Source:
Returns:
this party's share of the result.
- Type
- SecretShare
cdivfac(cst) → {SecretShare}
Division by a constant factor of the number represented by the share.
Parameters:
| Name | Type | Description |
|---|---|---|
cst |
number | the constant by which to divide the share. |
- Source:
Returns:
this party's share of the result.
- Type
- SecretShare
ceq(cst, op_idopt) → {SecretShare}
Equality test with a constant.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
cst |
number | the constant to compare with. | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. |
- Source:
Returns:
this party's share of the result, the final result is 0 if this = o, and 1 otherwise.
- Type
- SecretShare
cgt(cst, op_idopt) → {SecretShare}
Greater than with a constant.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
cst |
number | the constant to compare with. | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly.default ids suffice when all parties execute the instructions in the same order. |
- Source:
Returns:
this party's share of the result, the final result is 1 if this > cst, and 0 otherwise.
- Type
- SecretShare
cgteqn(cst, op_idopt) → {SecretShare}
Greater than or equal with a constant.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
cst |
number | the constant to compare with. | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. |
- Source:
Returns:
this party's share of the result, the final result is 1 if this >= cst, and 0 otherwise.
- Type
- SecretShare
change_threshold(threshold, op_idopt) → {SecretShare}
change of threshold for a single share
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
threshold |
number | the new threshold | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this multiplication (and internally, the corresponding beaver triplet). This id must be unique, and must be passed by all parties to the same instruction. this ensures that every party gets a share from the same triplet for every matching instruction. An automatic id is generated by increasing a local counter, default ids suffice when all parties execute the instructions in the same order. |
- Source:
Returns:
this party's share of the result under the new threshold
- Type
- SecretShare
clt(cst, op_idopt) → {SecretShare}
Less than with a constant.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
cst |
number | the constant to compare with. | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. |
- Source:
Returns:
this party's share of the result, the final result is 1 if this < cst, and 0 otherwise.
- Type
- SecretShare
clteq(cst, op_idopt) → {SecretShare}
Less than or equal with a constant.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
cst |
number | the constant to compare with. | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. |
- Source:
Returns:
this party's share of the result, the final result is 1 if this <= cst, and 0 otherwise.
- Type
- SecretShare
cmult(cst) → {SecretShare}
Multiplication by a constant.
Parameters:
| Name | Type | Description |
|---|---|---|
cst |
number | the constant to multiply to this share. |
- Source:
Returns:
this party's share of the result.
- Type
- SecretShare
cneq(cst, op_idopt) → {SecretShare}
Unequality test with a constant.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
cst |
number | the constant to compare with. | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. |
- Source:
Returns:
this party's share of the result, the final result is 0 if this = o, and 1 otherwise.
- Type
- SecretShare
cor_bit(cst) → {SecretShare}
bitwise-OR with a constant (BOTH BITS).
Parameters:
| Name | Type | Description |
|---|---|---|
cst |
number | the constant bit to OR with (0 or 1). |
- Source:
Returns:
this party's share of the result.
- Type
- SecretShare
csub(cst) → {SecretShare}
Subtraction with a constant.
Parameters:
| Name | Type | Description |
|---|---|---|
cst |
number | the constant to subtract from this share. |
- Source:
Returns:
this party's share of the result.
- Type
- SecretShare
cxor_bit(cst) → {SecretShare}
bitwise-XOR with a constant (BOTH BITS).
Parameters:
| Name | Type | Description |
|---|---|---|
cst |
number | the constant bit to XOR with (0 or 1). |
- Source:
Returns:
this party's share of the result.
- Type
- SecretShare
div(o, l, op_idopt) → {SecretShare}
Generic Integer Divison.
Uses either the constant or secret version of this operator depending on type of paramter.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
o |
number | SecretShare | the other operand (can be either number or share). | ||
l |
number | the maximum bit length of the two shares. | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. |
- Source:
Returns:
this party's share of the result.
- Type
- SecretShare
eq(o, op_idopt) → {SecretShare}
Generic Equals.
Uses either the constant or secret version of this operator depending on type of paramter.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
o |
number | SecretShare | the other operand (can be either number or share). | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. |
- Source:
Returns:
this party's share of the result.
- Type
- SecretShare
error()
Logs an error.
- Source:
gt(o, op_idopt) → {SecretShare}
Generic Greater than.
Uses either the constant or secret version of this operator depending on type of paramter.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
o |
number | SecretShare | the other operand (can be either number or share). | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. |
- Source:
Returns:
this party's share of the result.
- Type
- SecretShare
gteq(o, op_idopt) → {SecretShare}
Generic Greater or equal.
Uses either the constant or secret version of this operator depending on type of paramter.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
o |
number | SecretShare | the other operand (can be either number or share). | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. |
- Source:
Returns:
this party's share of the result.
- Type
- SecretShare
if_else(trueVal, falseVal, op_idopt) → {SecretShare}
Simulate an oblivious If-else statement with a single return value.
Should be called on a secret share of a bit: 0 representing false, and 1 representing true
If this is a share of 1, a new sharing of the element represented by the first parameter is returned,
otherwise, a new sharing of the second is returned.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
trueVal |
SecretShare | constant | the value/share to return if this is a sharing of 1. | ||
falseVal |
SecretShare | constant | the value/share to return if this is a sharing of 0. | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. |
- Source:
Returns:
a new sharing of the result of the if.
- Type
- SecretShare
logLEAK(tag, partiesopt) → {promise}
Logs the value represented by this share to the console.

Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
tag |
string | accompanying tag to display in the console. | ||
parties |
Array.<(number|string)> |
<optional> |
[holders[0] | the parties which will display the log. |
- Source:
Returns:
a promise to the value represented by this share after logging it, null if party is not in parties.
- Type
- promise
lt(o, op_idopt) → {SecretShare}
Generic Less than.
Uses either the constant or secret version of this operator depending on type of paramter.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
o |
number | SecretShare | the other operand (can be either number or share). | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. |
- Source:
Returns:
this party's share of the result.
- Type
- SecretShare
lt_halfprime(op_idopt) → {SecretShare}
Checks whether the share is less than half the field size.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. |
- Source:
Returns:
this party's share of the result.
- Type
- SecretShare
lteq(o, op_idopt) → {SecretShare}
Generic Less or equal.
Uses either the constant or secret version of this operator depending on type of paramter.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
o |
number | SecretShare | the other operand (can be either number or share). | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. |
- Source:
Returns:
this party's share of the result.
- Type
- SecretShare
mult(o, op_idopt) → {SecretShare}
Generic Multiplication.
Uses either the constant or secret version of this operator depending on type of paramter.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
o |
number | SecretShare | the other operand (can be either number or share). | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this multiplication (and internally, the corresponding beaver triplet). This id must be unique, and must be passed by all parties to the same instruction. this ensures that every party gets a share from the same triplet for every matching instruction. An automatic id is generated by increasing a local counter, default ids suffice when all parties execute the instructions in the same order. Only used if secret multiplication is used. |
- Source:
Returns:
this party's share of the result.
- Type
- SecretShare
neq(o, op_idopt) → {SecretShare}
Generic Not Equals.
Uses either the constant or secret version of this operator depending on type of paramter.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
o |
number | SecretShare | the other operand (can be either number or share). | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. |
- Source:
Returns:
this party's share of the result.
- Type
- SecretShare
not() → {SecretShare}
Negation of a bit.
This has to be a share of a BIT in order for this to work properly.
- Source:
Returns:
this party's share of the result (negated bit).
- Type
- SecretShare
open(partiesopt, op_idsopt) → {promise|null}
Shortcut for opening/revealing the value of this share. Alias for open in jiff-instance.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
parties |
Array |
<optional> |
all_parties | an array with party ids (1 to n) of receiving parties. |
op_ids |
string | number | object |
<optional> |
auto_gen() | an optional mapping that specifies the ID/Tag associated with each open message sent. |
- Source:
- See:
Returns:
a (JQuery) promise to the open value of the secret, null if the party is not specified in the parties array as a receiver.
- Type
- promise | null
or_bit(o, op_idopt) → {SecretShare}
Generic OR for bits (both this and o have to be bits to work correctly).
Uses either the constant or secret version of this operator depending on type of paramter.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
o |
number | SecretShare | the other operand (can be either number or share). | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. Only used if secret or is used.. |
- Source:
Returns:
this party's share of the result.
- Type
- SecretShare
pick_promise(o) → {promise}
Joins the pending promises of this share and the given share.
Parameters:
| Name | Type | Description |
|---|---|---|
o |
SecretShare | the other share object. |
- Source:
Returns:
the joined promise for both shares (or whichever is pending).
- Type
- promise
receive_share(value)
Receives the value of this share when ready.
Parameters:
| Name | Type | Description |
|---|---|---|
value |
number | the value of the share. |
- Source:
refresh(op_idopt) → {SecretShare}
Reshares/refreshes the sharing of this number, used before opening to keep the share secret.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
op_id |
string |
<optional> |
auto_gen() | the operation id with which to tag the messages sent by this refresh, by default an automatic operation id is generated by increasing a local counter, default operation ids suffice when all parties execute the instructions in the same order. |
- Source:
Returns:
a new share of the same number.
- Type
- SecretShare
sadd(o) → {SecretShare}
Addition of two secret shares.
Parameters:
| Name | Type | Description |
|---|---|---|
o |
SecretShare | the share to add to this share. |
- Source:
Returns:
this party's share of the result.
- Type
- SecretShare
sdiv(o, lopt, op_idopt) → {SecretShare}
Integer divison with two shares (self / o)
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
o |
SecretShare | the share to divide by. | ||
l |
number |
<optional> |
log_2(self.Zp) | the maximum bit length of the answer. |
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. |
- Source:
Returns:
this party's share of the result.
- Type
- SecretShare
seq(o, op_idopt) → {SecretShare}
Equality test with two shares.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
o |
SecretShare | the share to compare with. | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. |
- Source:
Returns:
this party's share of the result, the final result is 1 if this = o, and 0 otherwise.
- Type
- SecretShare
sgt(o, op_idopt) → {SecretShare}
Greater than with another share.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
o |
SecretShare | the other share. | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. |
- Source:
Returns:
this party's share of the result, the final result is 1 if this > o, and 0 otherwise.
- Type
- SecretShare
sgteq(o, op_idopt) → {SecretShare}
Greater than or equal with another share.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
o |
SecretShare | the other share. | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. |
- Source:
Returns:
this party's share of the result, the final result is 1 if this >= o, and 0 otherwise.
- Type
- SecretShare
slt(o, op_idopt) → {SecretShare}
Less than with another share.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
o |
SecretShare | the other share. | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. |
- Source:
Returns:
this party's share of the result, the final result is 1 if this < o, and 0 otherwise.
- Type
- SecretShare
slteq(o, op_idopt) → {SecretShare}
Less than or equal with another share.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
o |
SecretShare | the other share. | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. |
- Source:
Returns:
this party's share of the result, the final result is 1 if this <= o, and 0 otherwise.
- Type
- SecretShare
smod(o, lopt, op_idopt) → {SecretShare}
Remainder with two shares (self % o)
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
o |
SecretShare | the modulus to apply | ||
l |
number |
<optional> |
log_2(self.Zp) | the maximum bit length of the answer. |
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. |
- Source:
Returns:
this party's share of the result.
- Type
- SecretShare
smult(o, op_idopt) → {SecretShare}
Multiplication of two secret shares through Beaver Triplets.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
o |
SecretShare | the share to multiply with. | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this multiplication (and internally, the corresponding beaver triplet). This id must be unique, and must be passed by all parties to the same instruction. this ensures that every party gets a share from the same triplet for every matching instruction. An automatic id is generated by increasing a local counter, default ids suffice when all parties execute the instructions in the same order. |
- Source:
Returns:
this party's share of the result.
- Type
- SecretShare
smult_bgw(o, op_idopt) → {SecretShare}
Multiplication of two secret shares through BGW protocol.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
o |
SecretShare | the share to multiply with. | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this multiplication (and internally, the corresponding beaver triplet). This id must be unique, and must be passed by all parties to the same instruction. this ensures that every party gets a share from the same triplet for every matching instruction. An automatic id is generated by increasing a local counter, default ids suffice when all parties execute the instructions in the same order. |
- Source:
Returns:
this party's share of the result.
- Type
- SecretShare
sneq(o, op_idopt) → {SecretShare}
Unequality test with two shares.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
o |
SecretShare | the share to compare with. | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. |
- Source:
Returns:
this party's share of the result, the final result is 0 if this = o, and 1 otherwise.
- Type
- SecretShare
sor_bit(o, op_idopt) → {SecretShare|SecretShare}
OR of two secret shares OF BITS.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
o |
SecretShare | the share to OR with. | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. |
- Source:
Returns:
-
this party's share of the result, the final result is 1 if this < o, and 0 otherwise.
- Type
- SecretShare
-
this party's share of the result.
- Type
- SecretShare
ssub(o) → {SecretShare}
Subtraction of two secret shares.
Parameters:
| Name | Type | Description |
|---|---|---|
o |
SecretShare | the share to subtract from this share. |
- Source:
Returns:
this party's share of the result.
- Type
- SecretShare
sub(o) → {SecretShare}
Generic Subtraction.
Uses either the constant or secret version of this operator depending on type of paramter.
Parameters:
| Name | Type | Description |
|---|---|---|
o |
number | SecretShare | the other operand (can be either number or share). |
- Source:
Returns:
this party's share of the result.
- Type
- SecretShare
sxor_bit(o, op_idopt) → {SecretShare|SecretShare}
bitwise-XOR of two secret shares OF BITS.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
o |
SecretShare | the share to XOR with. | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. |
- Source:
Returns:
-
this party's share of the result, the final result is 1 if this < o, and 0 otherwise.
- Type
- SecretShare
-
this party's share of the result.
- Type
- SecretShare
toString() → {string}
Gets a string representation of this share.
- Source:
Returns:
the id and value of the share as a string.
- Type
- string
valueOf() → {number}
Gets the value of this share.
- Source:
Returns:
the value (undefined if not ready yet).
- Type
- number
xor_bit(o, op_idopt) → {SecretShare|SecretShare}
Generic XOR for bits (both this and o have to be bits to work correctly).
Uses either the constant or secret version of this operator depending on type of paramter.
Parameters:
| Name | Type | Attributes | Default | Description |
|---|---|---|---|---|
o |
number | SecretShare | the other operand (can be either number or share). | ||
op_id |
string |
<optional> |
auto_gen() | the operation id which is used to identify this operation. This id must be unique, and must be passed by all parties to the same instruction, to ensure that corresponding instructions across different parties are matched correctly. Only used if secret xor is used.. |
- Source:
Returns:
-
this party's share of the result, the final result is 1 if this < o, and 0 otherwise.
- Type
- SecretShare
-
this party's share of the result.
- Type
- SecretShare


Thank you for visiting tennisclub.com. Our mission is to provide unrivalled and unbiased informative and resources to help any sports fan who enjoys a flutter make informed and value led decisions.
Our mission is to provide unrivalled and unbiased informative, resources to help any sports fan who enjoys a flutter make.
Fusce risus metus, placerat in consectetur eu...
Fusce risus metus, placerat in consectetur eu...
Fusce risus metus, placerat in consectetur eu...


Ticket ManagementAdmin Template
08:26 PM (2 hours ago)
Subject: Lorem Ipsum has been the industry's standard dummy text ever
Email<EMAIL_ADDRESS>Date: 15.03.2018
Dummy text of the printing and typesetting industry. Lorem Ipsum has been the dustrys standard dummy text ever since the 1500s, when an unknown printer took a galley of types and scrambleded it to make a type specimenen book. It hasn survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. when an unknown printer took a galley of types and scrambleded it to make a type specimenen book. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages Read more.
All the Lorem Ipsum generators on the Internet tend to repeat the predefined chunks as necessary, making this the first true generator on the Internet. It uses a dictionary of over 200 Latin words, combined with a handful of model sentence crisity structures, to generate Lorem Ipsum which looks reasonable. recently with.Dummy text of the printing and typesetting industryunknown printer took a galley of type. when an unknown printer took a galley of types and scrambleded it's stambanner to make a type specimenen book.survived not only five centuries, but also the leap into the electronic typesetting, remaining essentially unchanged.
Thanks and Regards Mark Smith


Portfolio
Home
Skills
About Me
Job History
Projects
Contact Me
Ethan M. Gruenemeier
Contact Me
Send an E-mail
Google Maps
Top


Customize the authors and posts that you want to read on Steemit. By
@jga
Hide search options
Type:
Search by Trending
Search by Created
Search by Hot
Search by Feed
Search by Blog
Search by Votes
Tags:
Hide resteems
Min reputation:
Max reputation:
Min payout:
Max payout:
Min votes:
Max votes:
Min comments:
Max comments:
Min body:
Max body:
Min comment payout:
Max comment payout:
Allowed tags:
Avoided tags:
Allowed authors:
Avoided authors:
Votes from:
No votes from:
No upvoting bots
Older than:
Explorer:
https://steemit.com
https://busy.org
https://utopian.io
https://chainbb.com
https://steemd.com
https://steemblockexplorer.com
Other
Search
No recent posts!
Looking for older posts. Please wait.
Error loading!
Try it again.
Problems with the connection!


- Example Configuration
- Configuration File
- Grouping entries into metasites
- Single user (upgrade to 3.5)
- Singularity
- glExec
- Private Networks
- Security
- TCP Updates
- Adding custom files/scripts to the glideins
- Multiple Collectors
- Multiple HTCondor Tarballs
- XSLT Plugins to extend configuration
- Glidein's Startd Advertising to Site HTCondor-CE Collector
Example Configuration
Below is an example Factory configuration xml file.  It contains both global arguments as well as specific configuration to each entry point. At least one entry point must be specified in the configuration file.
The tags of the XML configuration file are described below. Each is given a designation:
- Required: You must change or examine this in order for the Factory to function correctly.
- Recommended: The installer provides a good default, but you should examine this attribute to make sure it is correct for your installation.
- Optional: The installer-provided default is likely correct for your installation. Change this only if your particular configuration requires special treatment or fine-tuning.
Global arguments
Global arguments are common to all entry points but can be overridden by individual entry point configuration.
-
<glidein ... >
Required: The main tag of the Factory configuration. See below for the parameters for this tag:
-
<glidein glidein_name="your name">Required: The name of the configuration. It will be used to advertise the entry points, will be defined as HTCondor glidein attribute GLIDEIN_Name, and is used also to create the directory names. Choose a short name that describes the set of Grid resources . It represents and append a version number (like "fnalcms_1"). Starting with v2.0 of GlideinWMS, you can use the Factory reconfig tool to make changes to the Factory configuration. You will only need new configuration for the factories during major upgrade. For more details refer the Glidein Factory management section
-
<glidein factory_name="your name">Recommended: Changing this value from the name of the machine allows you to move the Factory without disrupting the system.
-
<glidein schedd_name="schedd name[,schedd name]*">Recommended: If you want to use multiple HTCondor schedds or you don't like the default name, you definitely need to set this. If you specify more than a single schedd, the various entries will be equally spread among all the listed schedds. Possible values include (but are not limited to):
<EMAIL_ADDRESS>"myschedd_g1@mymachine.mydomain,myschedd_g2<EMAIL_ADDRESS>-
<glidein factory_collector="collector_name:port">Recommended: You can have a dedicated collector serving just for message passing with the Frontend.
If this is not set, the default collector will be used, which also happens to be used to advertise the internal HTCondor-G ClassAds. That's undersirable both for security reasons, and also because frequent HTCondor-G updates tend to load it heavily. -
<glidein loop_delay="seconds" advertise_delay="nr" >Optional: Defines how active the glidein Factory should be. The glidein Factory works in polling mode. loop_delay defines how much time should pass between each polling loop, with the collector being updated every advertise_delay loops.
-
<glidein restart_attempts="nr" restart_interval="seconds" >Optional: Defines how many times restart_attempts should be applied within restart_interval seconds for an entry if the entry crashes.
-
<glidein advertise_with_tcp="True|False" >Optional: Defines if the Factory should use TCP to advertise its ClassAds.
-
<glidein advertise_with_multiple="True|False" >Optional: Defines if the Factory should use -multiple to advertise its ClassAds.
-
<glidein advertise_pilot_accounting="True|False" >Optional: Defines if the Factory should condor_qedit pilot jobs after they finishes to add accounting information. A ClassAd MONITOR_INFO will be added and jobs will be left in the Complete state for 12 hours.
-
-
<glidein><log_retention><process_logs><process_log max_days="max days" min_days="min days" max_bytes="max bytes" type="INFO" backup_count="backup count" compression="gz"/>
The admin can configure one or more logs with any combination of following log message types:
- INFO: Informational messages about the state of the system.
- DEBUG: Debug message. These are additional informational messages that describe code execution in detail.
- ERR: Error messages. These may include tracebacks.
- WARN: Warning messages. These warn of conditions that were found that don't necessarily cause abnormal execution.
- ADMIN: This is a special setting only applicable to Factory logs (and not entry logs) that contains admin messages, such as reconfig comments. This will create a new log called factoryadmin.extension.log. Currently, it cannot be combined with other message types.
Log Retention and Rotation Policy:
Log files are rotated based on a time and size of the log files as follows:- If the log file size reaches max_bytes it will be rotated (NOTE: the value will be truncated and 0 means no rotation).
- If the log file size is less that max_bytes but the file is older than max_days, it will be rotated.
- min_days is not used and is there for backwards compatibility.
- Rotated files may be compressed. Supported compressions are Gzip "gz" and Zip "zip". Default is no compression (empty string).
- After rotation, recent number of backup_count files will be kept and older ones are deleted. Defaults to 5.
-
<glidein><condor_tarballs><condor_tarball os="os" arch="arch" base_dir="directory" version="condor version"/>
Required: Where to find the HTCondor binaries. You can list as many as you need, but at least one is required. This lets you configure glideins for different sites to use different version of HTCondor binaries based on architecture, OS of the worker nodes that could be found on the site.
It is recommended to have one default entry with os="default" arch="default" version="default".
To configure multiple tarballs, OS, arch and version accept a comma separated list. See multiple tarballs for more detailed instructions on supporting tarballs for multiple architectures. -
<glidein><submit base_dir="directory" base_log_dir="log directory" base_client_log_dir="client log directory" base_client_proxies_dir="directory where proxies will be stored" num_factories="1"/>
Recommended: Where to create the glidein submit directory. The default is the user home directory. Log directories can be configured independent of the base directory using options mentioned above. num_factories is a scaling factor used to scale down max_glideins, max_held, and max_idle for the entries.
-
<glidein><stage base_dir="web dir" web_base_dir="URL"/>
Recommended: These two define where the Web server directories are located.
The defaults are reasonable, but you may have different needs. -
<glidein><monitor base_dir="web dir" javascriptRRD_dir="web dir" flot_dir="web dir" jquery_dir="web dir>" >
Recommended: The base_dir defines where the monitoring web are is.
The other entries point to where javascriptRRD, Flot and JQuery libraries are. -
<glidein><monitor_footer display_txt="Legal Disclaimer" href_link="/site/disclaimer.html" />
OPTIONAL: If the display text and link are configured, the monitoring pages will display the text/link at the bottom of the page.
-
<glidein><security reuse_oldkey_onstartup_gracetime="900" remove_old_cred_age="30" remove_old_cred_freq="24" pub_key="RSA"/>
The Factory can remove old credential files saved on disk. You can set the min age (in days) the credential needs to be before it can be deleted and the frequency (in hours) to perform the removal. If you set the frequency to less than zero, the clean up functionality is disabled.
-
<glidein><security><frontends><frontend name="FrontendName" identity="username_usedby_factory@factory_hostname" />
Recommended: This configures the Frontend. Frontend on the Frontend hosting machine should have the same name as mentioned in the 'name'. Identity tells the Factory the username under which the Factory should map the given Frontend to. If this does not match the Frontend configuration, the Factory will drop all requested glideins.
-
<glidein><security><frontends><frontend><security_classes><security_class name="frontend" username=">username_usedby_factory"/>
Required: Tells the class and user name the Factory uses for this Frontend.
- <security_class name="frontend" username="username_usedby_factory"/> -
<glidein><attrs><attr name="attr name" value="value" const="True" parameter="True" publish="True" glidein_publish="True" comment="comment" />
Attributes you want to publish that effect all the Factory entries
To set specific attributes to an entry point, set them in /glidein/entries/entry/attrs section.
Table below describes the <attrs ... > tag.
Attribute Name
Attribute Description
name
Name of the attribute
value
Value of the attribute
const
Set to True if the attribute is a constant. If so, Glidein Frontend can not change it. If set to const, the attribute will be available in the constants file created in the staging area.
parameter
Set True if the attribute should be passed as a parameter. Always set this to True unless you know what you are doing.
publish
If set to True, the attribute will be published in Factory's ClassAd
glidein_publish
If set to True, the attribute will be available in the condor_startd's ClassAd (and the glidein condor configuration). Used only if parameter is True.
job_publish
If set to True, the attribute will be available in the user job's environment. Used only if parameter is True.
comment
You can specify description of the attribute here.
type
Type of the attribute. Supported types are 'int', 'string' and 'expr'. Typeexpr is equivalent to condor constant/expression in condor_vars.lst
These are used by the VO Frontend matchmaking and job matchmaking.
Example attributes are:<attrs> <attr name="VOpilot" value="CMS" publish="True" parameter="True" const="True" glidein_publish="True" comment=“A test attribute”/> <attr name="CondorVersion" value="v6.9.1" publish="True" parameter="True" const="True" glidein_publish="True"/> </attrs>
A list of all the attributes can be found on the dedicated configuration variables page.
-
<glidein><files><file absfname="script name" executable="True" period="period in seconds" prefix="cron prefix" after_entry="True" comment="comment" />
Custom files configuration is discussed in the Adding custom files/scripts to the glideins paragraph in the advanced section below.
Custom files (how to write and use them), are discussed in the custom scripts page.
The other arguments are for advanced admins only, and are
explained in a dedicated section.
Entry point arguments
The following are arguments that are specific to each entry point. They override the global arguments if present.
-
<glidein><entries><entry name="entry name">
Required: Each entry point will have its own root tag with parameters:
-
<glidein><entries><entry name="entry name">Required: Specify an easy name to remember, that will identify this entry for display purposes and for specifying using command line tools.
-
<glidein><entries><entry name="entry name" auth_method="grid_proxy">Required: The authentication method this entry supports. It is advertised to the Frontends to show which credentials are required for submission. Valid values: grid_proxy, voms_proxy, key_pair, cert_pair, username_password, vm_type, vm_id, project_id
Multiple authentication methods may be needed and there may be reqirements on the authentication method depending on the type of entry. E.g. ec2 requires a credential pair (key_pair, cert_pair, username_password) and the VM id and type. BOSCO requires a key_pair and a grid_proxy. The authentication method then must be <entry auth_method="grid_proxy+project_id" >.
When multiple methods are needed these can be additional entry values: <entry vm_type="vmtype" or vm_id="vmid" >
OR
can be added to the authentication method so the Frontend is required to pass them: <entry auth_method="key_pair+vm_id+vm_type" >
-
<glidein><entries><entry name="entry name" trust_domain="OSG">Required: The trust domain for the entry. This is not interpreted by the Factory code, only used to show what credentials are valid. For example, there may be two ec2-type entries for two different clouds with the authentication method of "key-pair". This shows allows the Frontend to map a key pair to a particular cloud. Or in BOSCO you can use it to select the key to use with a specific cluster.
-
<glidein><entries><entry name="entry name" gatekeeper="gatekeeper">Required: The identifier of your Grid/BOSCO resource (like "cmsitbsrv01.fnal.gov/jobmanager-condor"). BOSCO resources are USER@FQDN, e.g<EMAIL_ADDRESS>-
<glidein><entries><entry name="entry name" rsl="rsl">Please check the Grid site documentation and/or ask the Grid site administrator for the proper rsl and queue name for the site.
(example: '(condorsubmit=(universe vanilla)(requirements \"(ISMINOSAFS=?=True)\"))').
NOTE: If the auth_method contains "+project_id" for a TeraGrid entry, the string "(project=TG_PROJECT_ID)" will be added by the Factory and populated with the project id passed in the request. -
<glidein><entries><entry name="entry name" gridtype="grid type [default: condor]">Optional: The default condor is for HTCondor-CE Gatekeepers. Other values are ec2 or one of the batch types supported by HTCondor: batch pbs (for PBS and SLURM), batch lsf, batch sge, batch condor. This tag can specify additional HTCondor Grid types.
-
<glidein><entries><entry name="entry name" work_dir="WN dir">Recommended: This argument defines where the glidein should run once on the worker node.
Options are: ".", Condor (CONDOR), OSG, TMPDIR, AUTO
-
".": run in pwd
-
Condor (CONDOR): will run in $_CONDOR_SCRATCH_DIR
-
OSG: will run in $OSG_WN_TMP
-
TMPDIR: will run in $TMPDIR
-
AUTO: will try to determine which direcotry has enogh space (at least 1 GB of free space). Directory checked are $_CONDOR_SCRATCH_DIR, $OSG_WN_TMP $TG_NODE_SCRATCH, $TG_CLUSTER_SCRATCH, $SCRATCH $TMPDIR, $TMP, $PWD (in this order)
-
".": run in pwd
-
<glidein><entries><entry name="entry name" bosco_dir="BOSCO dir [default: bosco]">Optional: This argument defines the directory where BOSCO (some HTCondor executables and Glite BLAHP) are installed on the BOSCO resource submit host. This is the node specified in the gatekeeper attribute when using "batch ..." grid type. This is ignored for other grid types. The path specified is relative to $HOME. Note: This must be the same directory used for the BOSCO installation on the remote resource (bosco_cluster_add). A different directory is useful only to avoid interferences if the same home directory is shared and mounted by multiple resources.
-
<glidein><entries><entry name="entry name" proxy_url="Proxy URL">Recommended: If you have a Web cache you can use, you set it here (like "cmsitbsquid002.fnal.gov:3128"). On OSG resources, you can set it to "OSG", and the default OSG squid will be used. If you cannot use any Web cache server, you can skip this argument (the default is not to use caching). If defined, the user jobs will be able to use it as "GLIDEIN_Proxy_URL" environment variable.
-
<glidein><entries><entry name="entry name" schedd_name="schedd name">Optional: If you have an entry that needs a dedicated schedd, you can set it here (to something like<EMAIL_ADDRESS>-
<glidein><entries><entry name="entry name" enabled="True/False">Optional: You can define an entry point even if you do not plan to use it right away. The entry point directory will be created independently of the enabled flag, but will only be used by the glidein Factory if it is set to True. (Defaults to True).
-
<glidein><entries><entry name="entry name" verbosity="std/fast/nodebug">Optional: Specify the verbosity level and termination time in case of validation errors:
- std (default) – reasonable verbosity (including the condor log files) and 20min sleep in case of error (to reduce the damage resulting from broken nodes)
- fast – same verbosity as std, but will only wait 2 mins before terminating in case of error (good for debugging)
- nodebug – very low verbosity, if you want to save on disk space
-
-
<glidein><entries><entry name="entry name">
<config>
<max_jobs num_factories="3">
<per_entry held="1000" idle="2000" glideins="10000"/>
<default_per_frontend held="50" idle="100" glideins="5000"/>
<per_frontends>
<per_frontend name="FRONTEND:SECURITY_CLASS" held="50" idle="100" glideins="5000"/>
</per_frontends>
<max_jobs/>
<release max_per_cycle="20" sleep="0.2"/>
<remove max_per_cycle="5" sleep="0.2"/>
<submit cluster_size="10" max_per_cycle="100" sleep="0.2" slots_layout="partitionable">
<submit_attrs>
<submit_attr name="RequestMemory" value="2000"/>
<submit_attr name="+GlideinSkipIdleRemoval" value="True" all_grid_types="True"/>
</submit_attrs>
</submit>
</config>The config section controls the glidein policies for the entry.
- The max_jobs section limits the number of glidins held, idle, and total (including running).
- <per_entry ... > specifies the limits per entry.
- <default_per_frontend ... > specifies default limits for each frontend-security class (for this entry).
- <per_frontend ... > overrides the limits for a specific frontend-security class.
- Release regulates how many glideins are released per cycle.
- Remove regulates how many glideins are removed per cycle.
- Submit limits how fast the glideins are submitted
and controls the glideins type. Each main loop (cycle) the glideins are submitted using
multiple condor_submit commands
- cluster_size limits how many glideins are submitted with one condor_submit command (if more glideins need to be submitted, multiple condor_submit invocations are used).
- sleep is the minimum wait between two condor_submit commands (actual time is longer).
- max_per_cycle limits how many glideins to submit every cycle
- slots_layout tells what kind of glideins the entry supports: "fixed" number of slots; or "partitionable" slots, which enables HTCondor's partionable/dynamic slots. The number of cores claimed by the glidein can be controlled by the GLIDEIN_CPUS variable. GLIDEIN_ESTIMATED_CPUS can provide an estimate used for matching when the number of cores is discovered automatically.
- <submit_attr ... > specifies additional HTCondor attributes to add to the HTCondor submit file that the Factory uses to submit pilots to a site. These attributes are only added when the gridtype is "batch SOMETHING" (using BOSCO) or "condor" or "ec2" or "gce". The attributes are ignored for all other grid types unless the attribute 'all_grid_types' is set to true.
-
The following submit attribute can be added to disable the temporary removal of idle glideins:
<submit_attr name="+GlideinSkipIdleRemoval" value="True" all_grid_types="True"/>
- The max_jobs section limits the number of glidins held, idle, and total (including running).
-
<glidein><entries><entry name="entry name"><attrs><attr name="attr name" value="value" const="True" parameter="True" publish="True" glidein_publish="True" comment="comment"/>
Attributes you want to publish into the HTCondor ClassAd. These are used by the VO Frontend matchmaking and job matchmaking.
Example attributes are:
<attr name="HasMySoftware" value="True" publish="True" parameter=" True" const="True" glidein_publish="True" comment=“My users cannot live without” /> <attr name="OS" value="Linux" publish="True" parameter="True" const="True" glidein_publish="True"/>
Other pre-defined attributes are listed below:-
<glidein><entries><entry name="entry name"><attrs><attr name="GLIDEIN_Site" value="value" const="True" parameter="True" publish="True"/>Recommended: This defines the glidein attribute GLIDEIN_Site, both for use of the Frontend and for the use of the job negotiation. Logically defining a site is useful, so that you can change entry points but the user jobs do still known where they are running. If not specified, it defaults to the entry point name in the startd ClassAd.
-
<glidein><entries><entry name=entry name"><attrs>Recommended: Select a non-default HTCondor binary.
<attr name="CONDOR_VERSION" value="os" type="string" const="True" parameter="True" publish="False" />
<attr name="CONDOR_ARCH" value="arch" type="string" const="True" parameter="True" publish="False"/>
<attr name="CONDOR_OS" value="version" type="string" const="True" parameter="True" publish="False"/>
The entry will default to CONDOR_OS="default" CONDOR_ARCH="default" CONDOR_VERSION="default", if not otherwise defined. -
<glidein><entries><entry name="entry name"><attrs><attr name="X509_CERT_DIR" value="value" const="True" parameter="True" glidein_publish="False" job_publish="True" publish="True"/>Recommended for BOSCO resources: BOSCO resources normally have no OSG software installed, so it is safer to publish the location of the CA certificates because the job may not be able to find them otherwise.
-
<glidein><entries><entry name="entry name"><attrs><attr name="GLIDEIN_CPUS" value="value" const="True" parameter="True" publish="True"/>Recommended: Specifies how many CPUs (cores) to claim on the compute node
Valid values are 1..N and "auto", "slot" or "node" (corresponding to 0, 0, -1) which means to use all cores on the slot or on the node (see it on the configuration variables page for more). The entry will default to 1 if not otherwise defined.
-
-
<glidein><entries><entry name="entry name"> <allow_frontends> <allow_frontend name="vofrontend_name" security_class="security_class_name"/>
This argument allows you to create a whitelist of VO Frontends that can access this entry point. If this tag is blank or missing, it is assumed that all VO Frontends can submit glideins to this entry point. However, if any allow_frontend tags exist, the entry point will only allow those Frontends to submit glideins. The name of the Frontend must match the name given in the security class above in the configuration.
For each Frontend, you must tell it which security classes (e.g. proxies) can use the Frontend. The Factory will only submit glideins on behalf of these security classes. If you want all security classes to be allowed, you can put "All" in this field. Otherwise, it must match the security class configuration higher up in the xml.
-
<glidein><entries><entry name="entry name"> <infosys_refs><infosys_ref ref="filename" server="SERVER" type="RESS/BDII"/>
This argument is placed here by the installers based on information from BDII/RESS. This gives you information on where the server's information was retrieved from. It can also be used to retrieve downtime information from RESS/BDII.
Grouping entries into metasites
Starting in v3.2.20, entries with similar configuration can be grouped in <entry_sets> to form what we call a metasite. <entry_sets> starts right after the <entries> tag is closed. A metasite is defined by starting an <entry_set>, which then contains the common configuration for the different entries, and then an <entries> tag containing the different entries for the metasite.
The following is an example of two different entry set containing two separate entries.
The attributes auth_method, gridtype, and trust_domain must be the same in all entry elements (they are used for credential generation in the Frontend).
Only the metasite will be advertized as a glideresource ClassAd, so the Frontend will only see one element (entry). The Frontend will apply limits transparently as before, and the Factory as well. Right before glidein submission, the Factory will detect there are multiple CE where the work can be send (multiple submission files) and it will count the running+idle glideins for each CE and send jobs to the one with less. The submission file is added to the job condor submit file for accounting purposes (GlideinEntrySubmitFile ClassAd).
The <entry_selection> parameter determines how the factory decides between the subentries of the metasite. By default the frontend requests are equally split among subentries until they are filled. Limits for the subentries correspond to the limits for the metasites divided by the number of subentries. More algorithms may be implemented in the future.
Advanced topics
While the above is enough for setting up a personal glidein pool on the local area network, you will need to do more fine tuning when deploying a larger one. In this section, the various advanced aspects of glidein pools will be presented.
Migration process for the removal of dependency of condor_root_switchboard (Upgrade to v3.5)
Starting v3.5, GlideinWMS stopped supporting Globus GRAM GT2/GT5 and Factory and all pilot jobs run under a single user (gfactory) to eliminate the need of switchboard and setuid/user-switching. Thus, all glideins will run using the Factory user (no more separated users per-VO). For the log and secure files, the same directory structure remains the same, only the ownership will change.
The transition for the new jobs is clear. But either for upgrading an existing Factory version from v3.4.x or ealier (even if there are no glideins)
or for the old glideins that are still running, there is a process which will ease the
migration process for this purpose. This process implies the execution of a script which:
1. Will change the ownership of the log and security file directories
2. Will run a sed command on the condor job_queue files to change ownership of jobs inside condor
First of all, to check what the script does, you must be located in factory/tools of your GWMS installation and execute like (add --debug for a more verbose output):
sudo fact_chown --user=gfactory --group=gfactory --test --backupThis execution should show you how the script works without making changes. It will also create a backup of the files that is going to modify in the current working directory. Please, notice that if you create the backup now, make sure that both condor and the factory are not running. Otherwise the backup might be out of date.
If you know what you are doing and, you would like actually to do the migration, please follow the following steps:
1. Stop Factory and stop condor. (This step is very important condor must not run when the script is being executed!)
2. Run the script fact_chown indicating the user and the group which the directories and their content will take the ownership. Add also the flag --backup to have backup of everything (or not if you are happy with a backup created previously). Example with backups (notice the absence of --test):
sudo fact_chown --user=gfactory --group=gfactory --backup3. Start condor and Factory and check the changes
Remember:
- Run the script with no options if you don't want to have backups.
- If you see the permissions have changed but not the ownership, make sure you have executed the script with condor stopped.
- If pilots go held after executing the script, make sure that you have executed the steps as indicated before. If condor was running during the script execution: stop condor, run the script again and release the jobs.
After executing these steps, you should see your jobs changed user in condor_q to the new owner. Also, the onwership to Factory user (gfactory) of:
- Log files directories in /var/log/gwms-factory/client/
- Security files directory in /var/lib/gwms-factory/client-proxies/
- All files and folders in the corresponding folder's tree indicated before:
- /var/log/gwms-factory/client/
- /var/lib/gwms-factory/client-proxies/
To revert to a previous version of GlideinWMS, you need to restore the job_queue files and change back the permissions of the log directories. As commented previously, those operations need to be performed with both condor and GlideinWMS stoppped.
- To restore the job_queue condor files: untar all the schedd_glideins1_job_queue.log.tar.gz files, and move the job_queue.log file into its original location. You can print it when you run the fact_chown script (you can also run it with --test and --skipchown)
- To restore the directory permissions for the logfiles, you can run the following command:
for dir in /var/log/gwms-factory/client/user_fe*; do USERARR=(${dir//_/ }); USER=${USERARR[1]}; chown -R $USER:$USER $dir; done
CCB - Condor Connection Broker
The detailed description of CCB is
beyond the scope of this manual and you should refer to the HTCondor
documentation available
here.
, where you will find only the parameters needed to enable it in the
glideins.
To use HTCondor with CCB, you need to specify:
[<entries><entry>]
<attrs>
<attr name="USE_CCB" value="True" publish="False" parameter="True"/>
and you are done. Just make sure you follow the suggested scalability guidelines described in the HTCondor manual.
Integration with Singularity
An entry can control the use of Singularity by setting GLIDEIN_SINGULARITY_REQUIRE to NEVER (Singularity is not supported), OPTIONAL or PREFERRED (capable of Singularity but it is not enforced), REQUIRED (jobs must run with Singularity) or REQUIRED_GWMS (jobs must run with Singularity and use the GWMS wrapper scripts). This last option is the only one that really enforces Singularity, but is not compatible with VOs that currently self-manage Singularity with custom scripts, like OSG and CMS. The attribute can be set in the general or entry <attrs> section of the Factory configuration: <attr name="GLIDEIN_SINGULARITY_REQUIRE" const="True" glidein_publish="True" job_publish="True" parameter="True" publish="True" type="string" value="REQUIRED"/>.
The value of GLIDEIN_SINGULARITY_REQUIRE is used by the Frontend to provision resources and by the Glidein to negotiate the use of Singularity with the jobs. An entry where Singularity is OPTIONAL or PREFERRED will allow to run without Singularity if the job prefers so or if Singularity fails. An entry requiring Singularity (REQUIRED, REQUIRED_GWMS) will not allow to run without Singularity and the Glidein will fail if Singularity fails (e.g. the singularity binary or the image are not found).If Singularity is allowed or required (all values of GLIDEIN_SINGULARITY_REQUIRE except NEVER), singularity is expected on all worker nodes of the entry. The Glidein will search a singularity binary in the PATH and then invoking Modules (if available). SINGULARITY_BIN is now deprecated. It should not be used and will be ignored in future versions of GWMS. Currently, for compatibility with previous versions, any value of SINGULARITY_BIN different from 'NONE' sets GLIDEIN_SINGULARITY_REQUIRE to OPTIONAL (if not already set) and if the content is a valid path, is considered in the search for singularity. Setting SINGULARITY_BIN to 'NONE' sets GLIDEIN_SINGULARITY_REQUIRE to NEVER (if not already set).
NOTE: For compatibility with previous versions and to ease the migration to the use of GWMS scripts, GLIDEIN_SINGULARITY_REQUIRE=REQUIRED works only if Singularity is managed via GWMS. GLIDEIN_Singularity_Use=GWMS_DISABLE in the Frontend configuration (default) allows VOs to manage Singularity independently from GWMS. GLIDEIN_SINGULARITY_REQUIRE=REQUIRED_GWMS will not accept jobs where GLIDEIN_Singularity_Use=GWMS_DISABLE. It is a stronger enforcement, but will not allow VOs managing Singularity on their own. Jobs with GWMS_DISABLE will not trigger Glideins on entries with REQUIRED_GWMS, and the Glidein will fail at setup setup if somehow this combination happens.
The Factory can specify a dictionary of available Singularity images using SINGULARITY_IMAGES_DICT. This can be overridden by the Frontend, unless the attribute is declared constant (const="True"). <attr name="SINGULARITY_IMAGES_DICT" const="False" glidein_publish="True" job_publish="True" parameter="True" publish="True" type="string" value="rhel6:/cvmfs/singularity.opensciencegrid.org/opensciencegrid/osgvo-el6:latest,rhel7:/cvmfs/singularity.opensciencegrid.org/opensciencegrid/osgvo-el7:latest"/>.
The Factory can specify bind-mounts for Singularity images using GLIDEIN_SINGULARITY_BINDPATH_DEFAULT. This can be overridden by the Frontend, unless the attribute is declared constant (const="True"). If one or more of the specified paths does not exist on the node, it will be removed from the list. <attr name="GLIDEIN_SINGULARITY_BINDPATH_DEFAULT" const="False" glidein_publish="True" job_publish="True" parameter="True" publish="True" type="string" value="/cvmfs,/src_path:/dst_path"/>.
The use of Singularity is negotiated according to the table below, using GLIDEIN_SINGULARITY_REQUIRE (from the Factory) and GLIDEIN_Singularity_Use (from the Frontend), resulting in DISABLE (do not use the GWMS Singularity mechanisms), FAIL (do not provision on this entry, do not match with these Glideins or fail the Glidein), NEVER (do not use Singularity), PREFERRED (use Singularity but allow to fall-back to no Singularity if something goes wrong, e.g. no image is found) or REQUIRED (use Singularity and fail the Glidein if it cannot run with Singularity).
The table below combines GLIDEIN_SINGULARITY_REQUIRE values (first row, in bold) and GLIDEIN_Singularity_Use values (first column, in bold) and the results are in the intersection.  While this has the advantage of simplifying the architecture and improve both efficiency and VO control, it does have a few problems:
All glidein scripts and HTCondor daemons, AND user jobs all run under the same Unix UID. So users can interfere with the glidein tasks, possibly hacking the system.
Plus, when several glideins start on the same node (on multi processor/core machines), one user job can interfere with another user job.The real user is never authenticated against the Grid site authorization infrastructure. This makes it impossible for the sites to enforce their policies, nor can they analyze the usage of their resources; they see only glideins. This makes them very unfriendly toward the glidein based WMS.
To solve this problem, some Grid sites are deploying gLExec on the worker nodes. gLExec is a service that will take the following:
- the user proxy, and
- the desired command
It will contact the local authorization and mapping system, switch to the UID of the user (as opposed to the glidein UID), and execute the provided command as that UID.
By using gLExec, a Glidein Factory can get rid of both of the above problems, and still keep all the advantages.
To enable gLExec support, you need to specify:
[<entries><entry>]
<files>
<file absfname="web_base/glexec_setup.sh>" executable="True"/>
</files>
<attrs>
<attr name="GLEXEC_BIN" value="path to glexec" publish="False" parameter="True"/>
For most current gLExec installation this comes down to:
More details about scripts in general can be found in the "custom code" section.
You will also need to properly configure the shadow config files on the submit machine, by adding the following to the condor_config:
GLEXEC_STARTER = True
GLEXEC = /bin/false
Just some history information to understand about glexec: In the old gLExec operation mode, condor_startd invoked condor_starter through gLExec. The result was that ciondor_starter was running under the same UID as the user job, leaving it vulnerable to attack from a malicious user. The new operating mode solves this by having condor_starter run the user jobs via glexec; this adds a little more overhead to handle the user jobs, but makes the system much more secure.
To enable the new operation mode, add the following line to your configuration file:
Note that you still need to set GLEXEC_BIN, too.
Troubleshooting
gLExec installations on at least one site had problems with delegated proxies. If in doubt, try to disable the delegation.
To disable delegation, add the following to the shadow configuration file:
DELEGATE_JOB_GSI_CREDENTIALS=False
SEC_DEFAULT_ENCRYPTION=PREFERRED
Then, set the following tags in the glidein creation file:
[<entries><entry>]
<attrs> <attr name="SEC_DEFAULT_ENCRYPTION" value="REQUIRED" publish="False" parameter="True"/>
Another thing to consider is the startup directory; it must be accessible by both: the starting user and the target user(s). The directory you usually start in the Grid is most often not readable by any other user, so you must select something else. Both HTCondor and OSG should be fine, or you can specify any other fixed, WN-local location.
Private networks and firewalls
HTCondor daemons need two way communication in order to work properly. This clashes with the network policies of most Grid sites, that have worker nodes in private networks or implement a restrictive firewall.
HTCondor provides the CCB mechanism to address this. It was providing also a second mechanism, GCB, but it is no more supported in recent versions, so remove it if you still have it in your configuration.
CCB - Condor Connection Broker
The detailed description of CCB is
beyond the scope of this manual and you should refer to the HTCondor
documentation available
here.
, where you will find only the parameters needed to enable it in the
glideins.
To use HTCondor with CCB, you need to specify:
[<entries><entry>]
<attrs>
<attr name="USE_CCB" value="True" publish="False" parameter="True"/>
and you are done. Just make sure you follow the suggested scalability guidelines described in the HTCondor manual.
Security handles
As mentioned in the startup
page, the glidein pool must be properly configured to protect it
from hackers and malicious users. The same page also describes what
needs to be done on the collector machine.
The glidein itself can
also be configured. The default configuration works fine for most
users, but you may need to change them.
The values are set
using the <attr /> option,
and the default values are:
- SEC_DEFAULT_ENCRYPTION=OPTIONAL
- SEC_DEFAULT_INTEGRITY=REQUIRED
- DELEGATE_JOB_GSI_CREDENTIALS=False
HTCondor also supports a more efficient authentication mechanism between the condor_schedd/condor_shadow and condor_startd/condor_starter. This method uses the match ClaimId as a shared password for authentication between these daemons. Since using a shared secret is much cheaper that using GSI authentication, this should be used every time it is feasible.
This option is enabled by default. <attr /> option:
<attr name=USE_MATCH_AUTH ... value=True.. /> ... enabled
<attr name=USE_MATCH_AUTH ... value=False.. /> ... disabled
When enabled, this HTCondor attribute must be set in the
condor_config of the submit machine.
This option is not used by the HTCondor negotiator or collector and therefore
not needed if they are installed separately.
SEC_ENABLE_MATCH_PASSWORD_AUTHENTICATION = True
Using TCP to send updates to the Collector
By default, HTCondor uses UDP packets to communicate between the glideins and the Collector. While more efficient than TCP, UDP packets are often blocked at the firewall, or lost on the WAN.
To disable TCP updates, specify, with the <attr/> option:
UPDATE_COLLECTOR_WITH_TCP=False
In GlideinWMS, we enable the glideins to update the user collector using TCP by default.
Please be aware that this will configure the glideins only; you
still need to properly configure the Collector machine. See
Condor documentation
for more details.
Multiple Collectors
By default, HTCondor uses only one Collector for the glidein (user) pool. However, if the load becomes too high on the collector, you can configure multiple collectors in a chain.
You will need a master and a set of slave collectors. Each slave collector will service a portion of the pool and will forward communication between the startd daemons to the master collector. Machine ClassAds from these startd's will be sent to the master collector. The negotiator and the schedds will talk to the master collector, and the startds will talk to one of the slave ones. This will reduce load on the central manager.
To set up slave collector in the glidein (user) pool, one way is to set the following env variables before starting up the condor_master:
COLH=`condor_config_val COLLECTOR_HOST` LD=`condor_config_val LOCAL_DIR` export _CONDOR_COLLECTOR_HOST=$COLH: export _CONDOR_MASTER_NAME=collector_ export _CONDOR_DAEMON_LIST="MASTER, COLLECTOR" export _CONDOR_LOCAL_DIR=$LD/$_CONDOR_MASTER_NAME export _CONDOR_LOCK=$_CONDOR_LOCAL_DIR/lock # Forward all the traffic to the main collector export _CONDOR_CONDOR_VIEW_HOST=localhost:9618
Using
Once you have the slave collectors set up, you will want to use them.
The VO Frontend will have to point the Factory to a list of collectors.
The configuration internally will add a line in the Factory configuration file that will set up the glideins to handle the multiple collectors. (You should now see a line like: "<file absfname="web_base/collector_setup.sh" executable="True"/>" after reconfiguring).
Setting the glidein start and rank condition
As with any HTCondor pool, you may need to set the startd
start
and rank
conditions.
For a glidein, you can set this with the <attr/> options:
GLIDEIN_Start=expression
GLIDEIN_Rank=expression
For example:
[<entries><entry>]
<attrs>
<attr name="GLIDEIN_Start" value="Owner=="sfiligoi"" publish="False" parameter="True"/>
<attr name="GLIDEIN_Rank" value="ImageSize" publish="False" parameter="True"/>
Internal Configuration
The configuration is parsed during the reconfiguration of the Factory, and split into a number of files:- job.descript => read by the daemon do decide how to work
- attributes.cfg => fixed values, these are published in the Factory ClassAd
- params.cfg => for values the Frontend will change, also published in the Factory ClassAd
Multiple Condor Tarballs
One frequent problem is that one particular condor binary will not run on all compute nodes. Entry points require different architectures, or have different versions of glibc.
The solution is to have multiple condor binaries. The way to do this is to specify a tarball tag in the Factory configuration file.
- Download the HTCondor binary from the University of Wisconsin site. (Alternatively, You can build it from scratch on the architecture. Refer to HTCondor instructions for this.) The glideinwms pilot uses a subset of the condor binaries/libraries. The create_condor_tarball script can be used to reduce space needed on your Factory node. Details on this script can be found in the Components - Tools section of the documentation.
- Add a new condor_tarball tag to the Factory configuration file:
There are two different ways you can do this:- Put the tarball in a directory owned by the wmsfactory and
enter the condor_tarball tag as:
<glidein ... >
...
<condor_tarballs >
<condor_tarball os="OS" arch="Arch" tar_file="ZIPPED_TARFILE" version="Condor_Version" /> - Put the tarball in a directory owned by the wmsfactory and unzip/untar it.
Then, enter the condor_tarball tag as:
<glidein ... >
...
<condor_tarballs >
<condor_tarball os="OS" arch="Arch" base_dir="DIR_OF_UNTARRED_BINARY" version="Condor_Version" />
Consider an example below for default OS as rhel5 and default arch as x86_64. If the Factory admin also wants os and arch information explicitly available, the configuration needs following entries to cover possible combinations.<condor_tarball os="default" arch="default" base_dir="dir" version="default"/>
Above example can be easily consolidated into a single condor_tarball entry as below and the Factory reconfiguration process will internally consider all the combinations. This also applies to the version.
<condor_tarball os="rhel6" arch="x86_64" base_dir="dir" version="default"/>
<condor_tarball os="rhel6" arch="default" base_dir="dir" version="default"/>
<condor_tarball os="default" arch="x86_64" base_dir="dir" version="default"/><condor_tarball os="default,rhel6" arch="default,x86_64" base_dir="dir" version="default"/>
- Put the tarball in a directory owned by the wmsfactory and
enter the condor_tarball tag as:
- Verify your entry point attributes. Each entry point will have the following attr set up. Make sure that this matches the above condor_tarball parameters:
<entry>
The CONDOR_OS and the CONDOR_ARCH should match the os and arch defined in the tarball tag. If set to "auto", the glidein will decide the appropriate tarball to use for that worker node. By default, the CONDOR_VERSION will be defined globally in <glidein><attrs> and should match the version in the condor_tarball tag. You can overwrite this global version and define one locally in the entry if needed.
<attrs>
<attr name="CONDOR_ARCH" const="True" parameter="True" glidein_publish="False" job_publish="False" publish="False" type="string" value="Arch"/>
<attr name="CONDOR_OS" const="True" parameter="True" glidein_publish="False" job_publish="False" publish="False" type="string" value="Condor_Version"/>
<attr name="GLEXEC_JOB" const="True" parameter="True" glidein_publish="False" job_publish="False" publish="False" type="string" value="True"/>
  </attrs>
- Reconfigure the Factory using the command:
./factory_startup reconfig ../CONFIG_DIR/glideinWMS.xml
-
After reconfig, you can see the tar_file created from the
condor distribution in the condor_tarball element in the configuration
as (if you populated just tar_file in step 2
<condor_tarball arch="default" os="default" tar_file="FACTORY_DIR/condor-8.7tgz" version="default"/>
or (if you populated just base_dir in step 2)<condor_tarball arch="default" base_dir="/opt/glideins/git-xen21-master-ps.ini/condor-wms" os="default" tar_file="/var/www/html/glideinwms/factory_service/stage/glidein_master/condor_bin_0.d7bbk9.tgz" version="default"/>
Limiting time spent on a Grid resource
The whole concept of gliding into Grid resources is based on the
idea that you are getting those resources on a temporary basis.
This implies that you need to leave the slot as soon as possible,
else your jobs will simply be killed by the annoyed Grid
administrators.
On the other hand, submitting new glideins is not
cost free, so you want to keep the resource for at least some period
of time.
The glideins have two mechanisms to regulate this:
After a specified amount of time, the glidein will enter the RETIRING state. This means, it will wait for the current job to finish (or kill it if it does not end within a configurable timeout) and exit immediately afterwards. This obviously implies that no new jobs will start after it entered that state.
The two timeouts can be set with the <attr /> options:GLIDEIN_Retire_Time=nr_of_seconds
GLIDEIN_Job_Max_Time=nr_of_secondsThe two default to 2 and 100 hours.
If a glidein is not claimed within a configurable timeout, the glidein will exit.
The timeout can be set with:GLIDEIN_Max_Idle=nr_of_seconds GLIDEIN_Max_Tail=nr_of_seconds
There are two configurable parameters for this timeout behavior. The first, GLIDEIN_Max_Idle, affects how long a glidein will wait for its first job. The second parameter is how long a glidein will wait to get a subsequent job once its finished its job. The defaults for these are 1200 and 400 seconds, respectively.
An example:
[<entries><entry>]
<attrs>
<attr name="GLIDEIN_Max_Idle" value="300" type="int" publish="False" parameter="True"/>
<attr name="GLIDEIN_Retire_Time" value="14400" type="int" publish="False" parameter="True"/>
<attr name="GLIDEIN_Job_Max_Time" value="180000" type="int" publish="False" parameter="True"/>
Old-style pseudo-interactive monitoring
The pseudo-interactive monitoring uses a dedicated startd in the glideins for monitoring purposes. This allows for monitoring even when the job starter enters the “Retiring” activity.
The side effect is that you do not have anymore the cross-VM statistics and the names of the slots is also different.
To enable the old mode, use:
Adding custom files/scripts to the glideins
While provided code should cover most of the general purpose use cases, some administrators may have additional needs. For these cases, the Glidein framework provides the possibility to download and process additional files. Both , Factory and Frontend configuration allow to specify lists of files either for all their glideins, for a specific entry (Factory), or job group (Frontend). These files can be scripts (executables), regular files or tarballs and depending on the options can be downloaded at different times (see the custom scripts document for more detils).
Note: Files and subsystems will be downloaded before the scripts. User provided scripts will be executed in the specified order, and before the HTCondor daemons are started up.
Here a list of the attributes of the files. Some examples follow below:| Attribute Name |
Attribute Description |
| absfname |
Path of the file on the server (Factory or Frontend) |
| executable |
True if the file is a script (executable, see example below), default is False |
| wrapper |
True if the file is a user wrapper (see example below), default is False |
| untar |
True if the file is a tarball that needs to be expanded (see example below), default is False |
| const |
If False the file is not constant (i.e. changes may happen without a reconfiguration of the Factory and the file cannot be checksummed), default is True |
| relfname |
Path to save the file, relative to the glidein main directory |
| period |
If period>0 is the period (in seconds) of the executable . Default is 0 (non periodic script). This is ignored for non executable scripts. (see the custom scripts document for more) |
| prefix |
STARTD_CRON prefix, it is prepended to all HTCondor variables generated by the script (see documentation).
This is ignored from anything different from a periodic executable script.
The default value is |
| comment |
Arbitrary comment string |
| after_entry |
If True, the script is executed after the entry scripts. Default is False for the Factory, default is True for the Frontend. (see the custom scripts document for more) |
| after_group |
If True, the Frontend script is executed after the group scripts. Default is False. Not considered in the Factory. (see the custom scripts document for more) |
-
<glidein>
[<entries><entry>]
<files>
<file absfname="script name" executable="True" prefix="cron_prefix" comment="comment"/>Path to the custom script. The script will be copied in the Web-accessible area, and when a glidein starts, the glidein startup script will pull it and execute it. If any parameters are needed, they can be specified using <attr />, or stored in a file (see below).
For more detailed information, see the page dedicated to writing custom scripts.<glidein>
[<entries><entry>]
<files>
<file absfname="script name" wrapper="True" comment="comment"/>Path to the wrapper custom script. The script will be copied in the Web-accessible area, and will be sourced just before a user job starts starts; i.e. it will become part of the user job wrapper.
-
<glidein>
[<entries><entry>]
<files>
<file absfname="local file name" relfname="target file name" const="Bool" executable="False" comment="comment"/>Path to the config file. The file will be copied in the Web-accessible area, and pulled by the glidein startup script when a glidein starts. It can be then used by any script (see above).
Note: Please be cautious in using the const flag; if set to False, the content of the file will not be verified by the glidein startup script and could be tampered in transit by a malicious user. So never put sensitive data (like the switch to disable security checks) in a changeable file. -
<glidein>
[<entries><entry>]
<files>
<file absfname="local file name" untar="True" comment="comment">
<untar_options cond_attr="conf_sw" dir="dir name" absdir_outattr="attr name"/>Sometimes it is useful to transfer a whole set of files, or even directories, and that is much easier to accomplish by means of a tarball. A subsystem is the glidein way to describe a compressed tarball that is delivered to the worker nodes, untarred in a separate directory and advertised to the other scripts.
- absfname: Path to the custom tar-ball. (like "/tmp/mytar_v12.5.tgz")
- conf_sw:
Name of a configuration switch.
(like "ENABLE_KRB5")
The tarball will be unpacked only if that parameter will be set to 1. Use the <attr /> switch to define the default value. A special name TRUE can be used to always untar it. - dir: Name of the subdirectory to untar it in. (like "krb5")
- absdir_outattr: Name of a
variable name. (like "KRB5_SUBSYS_DIR")
The variable will be set to the absolute path of the directory where the tarball was unpacked, if and only if the unpacking actually happened (else it will not be defined.) ENTRY_ will be prepended if if the <file> directive occurs in an entry.
Monitoring collectors
By default, the glideins talk to the VO Pool Collector only. This makes monitoring them from the Factory side extremely difficult.
To solve this, you can set up a Monitoring Collector tree that mirrors that of the VO Pool Collector, and tell the glideins to report there, too.
The configuration syntax is very similar to that of the
the VO Pool Collector, but using monitoring_collector instead of collector keyword.
For example:
<monitoring_colectors>
<monitoring_colector DN="/DC=org/DC=doegrids/OU=Services/CN=factmoncollector.fnal.gov" node="factmoncollector.fnal.gov" secondary="False" group="default" /></monitoring_colectors>
<monitoring_colector DN="/DC=org/DC=doegrids/OU=Services/CN=factmoncollector.fnal.gov" node="factmoncollector.fnal.gov:9620-9819" secondary="True" group="default" />
<monitoring_colector DN="/DC=org/DC=doegrids/OU=Services/CN=factmoncollector2.fnal.gov" node="factmoncollector2.fnal.gov" secondary="False" group="ha" />
<monitoring_colector DN="/DC=org/DC=doegrids/OU=Services/CN=factmoncollector2.fnal.gov" node="factmoncollector2.fnal.gov:9620-9919" secondary="True" group="ha" />
For more details, see the Frontend documentation.
Grouping glidein Entries for monitoring purposes
Certain monitoring graphs are useful when grouped together. You can use the “monitorgroups” tag as follows to group the entries together.
For example, below, entry1 and entry2 will be grouped together and the group information can be plotted against individual entry information.
<entries>
<entry name=“entry1” ...>
<monitorgroups>
<monitorgroup group_name="Group1"/>
<monitorgroup group_name="Group2"/>
</monitorgroups>
</entry>
<entry name=“entry2” ...>
<monitorgroups>
<monitorgroup group_name="Group1"/>
<monitorgroup group_name="Group4"/>
</monitorgroups>
</entry>
</entries>
</glidein>
XSLT Plugins to extend configuration
You can use XSL transformations (XSLT) to manage complex configuration files. During the reconfig process, the glidein Factory applies XSL transformations available to it in the directory configured by the environment variable GWMS_XSLT_PLUGIN_DIR. (It is also available by supplying the -xslt_plugin_dir option to the reconfig_glidein and reconfig_frontend commands as shown below.)
Setting the variable via sysconfig files are supported: /etc/sysconfig/gwms-factory for the Factory service and /etc/sysconfig/gwms-frontend for the Frontend service, with the following contents:
prompt$ cat /etc/sysconfig/gwms-factory # Configuration file for the Glideinwms services. # # Plugin directory to get xslt transformations from. # export GWMS_XSLT_PLUGIN_DIR=/etc/gwms-factory/plugin.dThe following sample XSLT adds a custom attribute to the configuration file used by the Factory.
<?xml version="1.0"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" > <xsl:template match="glidein/attrs"> <xsl:copy> <attr name="SOME_GWMS_ATTRIBUTE" const="False" glidein_publish="False" job_publish="False" parameter="True" publish="True" type="int" value="7000"/> <xsl:apply-templates select="@* | node()"/> </xsl:copy> </xsl:template> <xsl:template match="/ | @* | node()"> <xsl:copy> <xsl:apply-templates select="@* | node()"/> </xsl:copy> </xsl:template>
prompt$ reconfig_glidein -xslt_plugin_dir <xslt directory> [...] prompt$ reconfig_frontend -xslt_plugin_dir <xslt directory> [...]
Glidein's Startd Advertising to Site HTCondor-CE Collector
You can make glidein's HTCondor daemons advertise to site's local collector. There is no Glideinwms configuration that enable this and all the changes are on the site side.
-
Give glidein write access to the site collector
This is done by adding glidein's DN to gridmapfile of the site collector -
Set site collector info in the glidein's environment
Set the CONDORCE_COLLECTOR_HOST in the glidein's environmentCONDORCE_COLLECTOR_HOST=<site-local HTCondorCE collector address>


Before Change
write(traceback)
subheader("Stack")
start_frame = traceback.extract_stack()[0]
filename, start_line = frame.filename, frame.lineno
// write(frame)
// write(dir(frame))
// write("line", frame.line, type(frame.line))
// write("lineno", frame.lineno, type(frame.lineno))
After Change
yield
end_frame = traceback.extract_stack()[0]
assert start_frame.filename == end_frame.filename
with open(start_frame.filename) as source_file:
lines = slice(start_frame.lineno, end_frame.lineno)
source = "".join(source_file.readlines()[lines])
code.markdown(f"```\n{textwrap.dedent(source)}\n```")
// This is a necessary (but not sufficient) condition to establish that this
// is the proxy process.
_this_may_be_proxy = sys.argv[0] == "-m"
// In order to log all exceptions etc to the streamlit report after
// `import streamlit.io` we establish the proxy by calling get_delta_generator().


Sorry, this website is not currently available.
Please make a note of your support ID number if you need to get in touch with us about this. Your support ID is:<PHONE_NUMBER>6795586654