text:
# Production Readiness Review Process

Production readiness reviews are intended to ensure that features merging into
Kubernetes are observable, scalable and supportable, can be safely operated in
production environments, and can be disabled or rolled back in the event they
cause increased failures in production.

## Status

The process and questoinnaire are currently under development as part of the
[PRR KEP][], with a target that reviews will be needed for features going into 1.18.

During the 1.17 cycle, the PRR team will be piloting the questionnaire and other
aspects of the process.

## Questionnaire

#### Feature enablement and rollback

* **How can this feature be enabled / disabled in a live cluster?**
  - [ ] Feature gate
    - Feature gate name:
    - Components depending on the feature gate:
  - [ ] Other
    - Describe the mechanism:
    - Will enabling / disabling the feature require downtime of the control
      plane?
    - Will enabling / disabling the feature require downtime or reprovisioning
      of a node? (Do not assume `Dynamic Kubelet Config` feature is enabled).

* **Can the feature be disabled once it has been enabled (i.e. can we rollback
  the enablement)?**
  Describe the consequences on existing workloads (e.g. if this is runtime
  feature, can it break the existing applications?).

* **What happens if we reenable the feature if it was previously rolled back?**

* **Are there any tests for feature enablement/ disablement?**
  The e2e framework does not currently support enabling and disabling feature
  gates. However, unit tests in each component dealing with managing data created
  with and without the feature are necessary. At the very least, think about
  conversion tests if API types are being modified.

#### Rollout, Upgrade and Rollback Planning

* **How can a rollout fail? Can it impact already running workloads?**
  Try to be as paranoid as possible - e.g. what if some components will restart
  in the middle of rollout?

* **What specific metrics should inform a rollback?**

* **Were upgrade and rollback tested? Was upgrade->downgrade->upgrade path tested?**
  Describe manual testing that was done and the outcomes.
  Longer term, we may want to require automated upgrade/rollback tests, but we
  are missing a bunch of machinery and tooling and do that now.

#### Monitoring requirements

* **How can an operator determine if the feature is in use by workloads?**
  Ideally, this should be a metrics. Operations against Kubernetes API (e.g.
  checking if there are objects with field X set) may be last resort. Avoid
  logs or events for this purpose.

* **What are the SLIs (Service Level Indicators) an operator can use to
  determine the health of the service?**
  - [ ] Metrics
    - Metric name:
    - [Optional] Aggregation method:
    - Components exposing the metric:
  - [ ] Other (treat as last resort)
    - Details:

* **What are the reasonable SLOs (Service Level Objectives) for the above SLIs?**
  At the high-level this usually will be in the form of "high percentile of SLI
  per day <= X". It's impossible to provide a comprehensive guidance, but at the very
  high level (they needs more precise definitions) those may be things like:
  - per-day percentage of API calls finishing with 5XX errors <= 1%
  - 99% percentile over day of absolute value from (job creation time minus expected
    job creation time) for cron job <= 10%
  - 99,9% of /health requests per day finish with 200 code

* **Are there any missing metrics that would be useful to have to improve
  observability if this feature?**
  Describe the metrics themselves and the reason they weren't added (e.g. cost,
  implementation difficulties, etc.).

#### Dependencies

* **Does this feature depend on any specific services running in the cluster?**
  Think about both cluster-level services (e.g. metrics-server) as well
  as node-level agents (e.g. specific version of CRI). Focus on external or
  optional services that are needed. For example, if this feature depends on
  a cloud provider API, or upon an external software-defined storage or network
  control plane.
	For each of the fill in the following, thinking both about running user workloads
  and creating new ones, as well as about cluster-level services (e.g. DNS):
  - [Dependency name]
    - Usage description:
		- Impact of its outage on the feature:
		- Impact of its degraded performance or high error rates on the feature:

#### Scalability

* **Will enabling / using this feature result in any new API calls?**
  Describe them, providing:
  - API call type (e.g. PATCH pods)
  - estimated throughput
  - originating component(s) (e.g. Kubelet, Feature-X-controller)
  focusing mostly on:
  - components listing and/or watching resources they didn't before
  - API calls that may be triggered by changes of some Kubernetes resources
    (e.g. update of object X triggers new updates of object Y)
  - periodic API calls to reconcile state (e.g. periodic fetching state,
    heartbeats, leader election, etc.)

* **Will enabling / using this feature result in introducing new API types?**
  Describe them providing:
  - API type
  - Supported number of objects per cluster
  - Supported number of objects per namespace (for namespace-scoped objects)

* **Will enabling / using this feature result in any new calls to cloud
  provider?**

* **Will enabling / using this feature result in increasing size or count
  of the existing API objects?**
  Describe them providing:
  - API type(s):
  - Estimated increase in size: (e.g. new annotation of size 32B)
  - Estimated amount of new objects: (e.g. new Object X for every existing Pod)

* **Will enabling / using this feature result in increasing time taken by any
  operations covered by [existing SLIs/SLOs][]?**
  Think about adding additional work or introducing new steps in between
  (e.g. need to do X to start a container), etc. Please describe the details.

* **Will enabling / using this feature result in non-negligible increase of
  resource usage (CPU, RAM, disk, IO, ...) in any components?**
  Things to keep in mind include: additional in-memory state, additional
  non-trivial computations, excessive access to disks (including increased log
  volume), significant amount of data send and/or received over network, etc.
  This through this both in small and large cases, again with respect to the
  [supported limits][].

#### Troubleshooting
Troubleshooting section serves the `Playbook` role as of now. We may consider
splitting it into a dedicated `Playbook` document (potentially with some monitoring
details). For now we leave it here though, with some questions not required until
further stages (e.g. Beta/Ga) of feature lifecycle.

* **How does this feature react if the API server and/or etcd is unavailable?**

* **What are other known failure modes?**
  For each of them fill in the following information by copying the below template:
  - [Failure mode brief description]
    - Detection: How can it be detected via metrics? Stated another way:
      how can an operator troubleshoot without loogging into a master or worker node?
    - Mitigations: What can be done to stop the bleeding, especially for already
      running user workloads?
	  - Diagnostics: What are the useful log messages and their required logging
      levels that could help debugging the issue?
      Not required until feature graduated to Beta.
    - Testing: Are there any tests for failure mode? If not describe why.

* **What steps should be taken if SLOs are not being met to determine the problem?**

[PRR KEP]: https://github.com/kubernetes/enhancements/blob/master/keps/sig-architecture/20190731-production-readiness-review-process.md
[supported limits]: https://github.com/kubernetes/community/blob/master/sig-scalability/configs-and-limits/thresholds.md
[existing SLIs/SLOs]: https://github.com/kubernetes/community/blob/master/sig-scalability/slos/slos.md#kubernetes-slisslos

repository: jai/community

repo_name: jai/community


text:
---
layout: post
title: DBXTalk Driver Phase Three - Querying a database
categories:
- Pharo
tags:
- bash
summary: This is the second post in a series about the new DBXTalk database driver.
status: publish
type: post
published: true
---

This is the third post in a series about the new DBXTalk database driver.

##Statement Objects

Statement objects support fine-grain control over statements sent to a database. We can create a statement object by sending the *createMessage:* message to a connection object with a SQL statement string, or the *#createStatement* and then configuring the statement with the *statementString:* message.

{% highlight smalltalk %}
aStatement := connection createStatement: 'CREATE TABLE CATS (
	name varchar(50),
	owner varchar(50))'.

anotherStatement := connection createStatement.
anotherStatement statementString: 'SELECT * FROM CATS'.
{% endhighlight %}

Statement objects can be executed sending them the *execute* message. Executing a statement returns the same kind of results as using the *execute:* message from a connection object. In fact, the connection object uses a statement object underneath.

{% highlight smalltalk %}
result := aStatement execute.
result do: [ ... ].
{% endhighlight %}

Statement objects can be reused. We can send them multiple times the *execute* message and obtain our results multiple times. This is particularly useful to avoid statements with complex creations or already optimized by the database, as we will see in the following sections.

{% highlight smalltalk %}
result := aStatement execute.
result do: [ ... ].

"we can execute it again and obtain the same results"
aStatement execute do: [ ... ].
{% endhighlight %}

####Prepared Statements

Some statement objects can be *prepared*. A prepared statement is a statement that is sent to the database to pre-process it. The database server can pre-parse it, cache results or even the execution plan. Prepared statements show useful by reusing statements. A prepared statement can be prepared sending the *prepare:* message to a connection with a SQL statement string, or by sending the *prepare* message to an already existing statement.

{% highlight smalltalk %}
preparedStatement := connection prepare: 'SELECT * FROM CATS'.

anotherPreparedStatement := aStatement createStatement: 'SELECT * FROM CATS'.
anotherPreparedStatement prepare.
{% endhighlight %}

Although prepared statements benefits, they are not equally supported by every database nor driver. Different databases support the preparation of different kind of statements, and not all database drivers support prepared statements. On one side, when a database driver supports prepared statements, the statement is be sent to the database for its preparation immediately after the *prepare* message. If the sent statement cannot be prepared by the database, an exception will be thrown notifying it. On the other side, when a database driver does not support prepared statements, the statement will not be sent to the database nor fail. Indeed, it will continue to be an unprepared statement to provide a polymorphic interface to the user. We can send the message *supportsPreparedStatements* to a database connection to know if it supports prepared statements.

{% highlight smalltalk %}
aConnection supportsPreparedStatements
	ifTrue: [ ... ]
	ifFalse: [ ... ]
{% endhighlight %}

####Sanitizing SQL

Composing strings to create a SQL statement can be cumbersome but also an unsafe way of creating a query. Attackers may benefit from wrongly sanitized SQL to perform SQL injection: the injection of SQL attacks inside a query. For example, given the following query, we could be able to inject a DROP TABLE script if not correctly concatenated.

{% highlight SQL %}
SELECT * FROM TABLE WHERE name=<some param>
{% endhighlight %}

And get a SQL statement like this.

{% highlight SQL %}
SELECT * FROM CATS WHERE name='';DROP TABLE CATS;
{% endhighlight %}

Prepared statements provide means to safely insert parameters inside a SQL statement. These parameters or placeholders are denoted inside a query by different literals, depending on the database server. It is the work of the database and its driver to safely replace the placeholder by its correct value and handle the escaping of such code to avoid injection.

- Question mark placeholders (*?*) are positional placeholders. Their index is their order of appearance.
- Numbered placeholders are identified by a question mark or a dollar sign followed by an integer number (*?1*, *?2*, *$1*, *$2*). Their index is the number associated to them.
- Named placeholders are identified by a dollar sign, an at sign or a collon followed by an name number (*$name*, *@name*, *:name*). Their index is the number associated to them. Usually, two named placeholders with the same name need to be set only once as they denote the same value.

{% highlight SQL %}
SELECT * FROM TABLE WHERE name='?'
SELECT * FROM TABLE WHERE name='$1'
SELECT * FROM TABLE WHERE name=':name'
{% endhighlight %}

The DBXTalk driver, by pursuing a common interface between different database drivers, only proposes question mark placeholders (*?*) in a SQL statement.

A statement placeholders can be filled with arguments using the *bind:* message. The *bind:* message accepts as argument any Pharo object and will transform it accordingly to its database representation. If no bind is specified, it is responsability of the driver to decide what to do. For example, SQLite3 will interpret missing bindings as *NULL*.

{% highlight smalltalk %}
statement := connection prepare: 'SELECT * FROM CATS WHERE name='?''.
statement at: 1 bind: 'lutz'.
result := statement execute
{% endhighlight %}

If we try to do SQL injection using placeholder bindings, it will escape the argument creating a safe version of the SQL statement. In this case the injected code will be embedded inside a string and the query will execute safely.

{% highlight smalltalk %}
statement := connection prepare: 'SELECT * FROM CATS WHERE name='?''.
statement at: 1 bind: ''''';DROP TABLE TABLE;'.
result := statement execute.
{% endhighlight %}

{% highlight SQL %}
SELECT * FROM CATS WHERE name=''';DROP TABLE TABLE;'
{% endhighlight %}

A SQL statement can also contain many placeholders. In that case, the supplied bindings are set in order:

{% highlight smalltalk %}
statement := connection prepare: 'SELECT * FROM CATS WHERE name='?' OR owner='?''.
statement at: 1 bind: 'lutz'.
statement at: 2 bind: 'guille'.
result := statement execute.
{% endhighlight %}

{% highlight SQL %}
SELECT * FROM CATS WHERE name='''';DROP TABLE TABLE;
{% endhighlight %}

The placehoder bindings feature is, however, only supported from the database server and for prepared statements. For those drivers that do not include prepared statements, the DBXDriver provides with some escaping helpers. Escaping helpers try to sanitize locally the input parameters with a series of character escaping techniques. Note that local character escaping does not guarantee the safety of statement execution. They do indeed benefit from other complementary techniques such as input validation and correct database permission control.

####Statement Options

get auto generated keys

query timeout

####Next

TODO:
- table of what kind of statements can be prepared by database
- ask the database which kind of statements it supports for preparation
- maybe add an age to the cat to use only one example
- how to see the result description (column names and types)
- table of database types

license: MIT

branch_name: refs/heads/master

extension: md

license_type: permissive


text:
# Blacklist server

![blacklist server](https://user-images.githubusercontent.com/10347617/64910710-359f4100-d722-11e9-9cc0-071b06330edf.png)

## Content

* [Installation](#installation)
* [Using](#using)
* [License](#license)

## Installation

To get the latest version of Laravel Blacklist Server, simply require the project using [Composer](https://getcomposer.org):

```
composer require andrey-helldar/blacklist-server
```

Instead, you may of course manually update your require block and run `composer update` if you so choose:

```json
{
    "require": {
        "andrey-helldar/blacklist-server": "^2.0"
    }
}
```

Now, you can also publish the config file to change implementations (ie. interface to specific class):

```
php artisan vendor:publish --provider="Helldar\BlacklistClient\ServiceProvider"
```

## Using

First look at the [config](src/config/settings.php).

After installation, your application will accept incoming requests for the creation and verification of spammers in stop lists. To do this, you can use packet [andrey-helldar/blacklist-client](https://github.com/andrey-helldar/blacklist-client) or simply send a POST or GET request to address `https://<your-site.com>/api/blacklist`, passing the necessary parameters:

| field | required | comment |
|---|---|---|
| type | sometimes | available is: "email", "url", "ip", "phone" |
| value | yes | string |

In order for the server part to be able to add or check spammers on its own, you can install package [andrey-helldar/blacklist-client](https://github.com/andrey-helldar/blacklist-client) on it or go the more complicated way using facades:

```php
use Helldar\BlacklistServer\Facades\Blacklist;

return<EMAIL_ADDRESS>'email') : Helldar\BlacklistServer\Models\Blacklist
return<EMAIL_ADDRESS>// throw Helldar\BlacklistCore\Exceptions\BlacklistDetectedException if exists.
return<EMAIL_ADDRESS>: bool

return Blacklist::store('http://example.com', 'url') : Helldar\BlacklistServer\Models\Blacklist
return Blacklist::check('http://example.com') // throw Helldar\BlacklistCore\Exceptions\BlacklistDetectedException if exists.
return Blacklist::exists('http://example.com') : bool

return Blacklist::store('<IP_ADDRESS>', 'ip') : Helldar\BlacklistServer\Models\Blacklist
return Blacklist::check('<IP_ADDRESS>') // throw Helldar\BlacklistCore\Exceptions\BlacklistDetectedException if exists.
return Blacklist::exists('<IP_ADDRESS>') : bool

return Blacklist::store('+0 (000) 000-00-00', 'phone') : Helldar\BlacklistServer\Models\Blacklist
return Blacklist::check('+0 (000) 000-00-00') // throw Helldar\BlacklistCore\Exceptions\BlacklistDetectedException if exists.
return Blacklist::exists('+0 (000) 000-00-00') : bool
```

However, we recommend using the [client](https://github.com/andrey-helldar/blacklist-client).

### store

When sending a POST request to the address of server `https://<your-site>/api/blacklist` with the correct data.
Foe example:
```
POST https://<your-site>/api/blacklist
Content-Type: application/json

{
  "type": "email",
  "value"<EMAIL_ADDRESS>}
```

It will return a JSON object:
```json
{
  "type": "email",
  "value"<EMAIL_ADDRESS>  "expired_at": "2024-05-11 16:41:04",
  "created_at": "2019-09-14 11:45:04",
  "updated_at": "2019-09-14 16:41:04"
}
```

If the data being sent is filled incorrectly, the server will return an error with code 400 and the following JSON object:
```json
{
  "error": {
    "code": 400,
    "msg": ["<message of the error>"]
  },
  "request": {
    // incoming data
  }
}
```

For example:
```json
{
  "error": {
    "code": 400,
    "msg": ["The type must be one of email, url, phone or ip, null given."]
  },
 "request": {
   "type": "foo",
   "value"<EMAIL_ADDRESS> }
}
```

### exists

If the requested data is not found in the database, the site will return a 200 code:
```json
"ok"
```

If the requested data is found in the database, the site will return the code 423 (Locked):
```json
{
  "error": {
    "code": 423,
    "msg": ["Checked email<EMAIL_ADDRESS>was found in our database."]
  },
  "request": {
    "value"<EMAIL_ADDRESS>  }
}
```

If the data being sent is filled incorrectly, the server will return an error with code 400 and the following JSON object.
For example:
```json
{
  "error": {
    "code": 400,
    "msg": ["The value field is required."]
  },
  "request": {}
}

{
  "error": {
    "code": 400,
    "msg": ["The type must be one of email, url, phone or ip, null given."]
  },
  "request": {
    "type": "foo",
    "value"<EMAIL_ADDRESS>  }
}
```

## License

This package is released under the [MIT License](LICENSE).

repository: andrey-helldar/blacklist-server

gha_language: PHP

gha_license_id: MIT

repo_name: andrey-helldar/blacklist-server


text:
# neptune

**Note: I archived it because there is no way I am updating it ever again. The code is a huge mess and would require a complete rewrite.**

A hacked "client" made entirely in ChatTriggers.

[![forthebadge](https://forthebadge.com/images/badges/0-percent-optimized.svg)](https://forthebadge.com)
[![forthebadge](https://forthebadge.com/images/badges/made-with-javascript.svg)](https://forthebadge.com)
[![forthebadge](https://forthebadge.com/images/badges/contains-tasty-spaghetti-code.svg)](https://forthebadge.com)

To use this you must have the latest 1.8.9 Forge installed (<IP_ADDRESS>8) and have the latest ChatTriggers version (1.3.0+).
ChatTriggers: http://chattriggers.com/

If you find some spaghetti code and would like to improve it, feel free to make a pull request!

To open the GUI, press Right-CTRL, can be changed in the Keybinds menu.

There are also commands. Do ".help" to view them.

To set keybinds you have to use the default Minecraft keybind manager, might improve this myself one day.

This is more of a "proof of concept", not made to bypass cheat detection systems.

repository: Debuggingss/neptune

branch_name: refs/heads/main

repo_name: Debuggingss/neptune


text:
# IBM Developer Model Asset Exchange: Object Detector

This repository contains code to instantiate and deploy an object detection model as a web service in a Docker container. The input to the model is an image, and the output is a list of estimated class probabilities for the objects detected in the image. This is the first time I work with a powerful thing call *API*.

The original version is based on the [SSD Mobilenet V1 object detection model for TensorFlow](https://github.com/tensorflow/models/blob/master/research/object_detection/g3doc/detection_model_zoo.md), but I customized to use [my car detection model](https://github.com/manhitv/Object-Detection-Tensorflow).

You could follow instructions from [here](https://github.com/IBM/MAX-Object-Detector) to run the code locally or deploy the model as a web service.

If you want to use your model, just change properly two files: **config.py** and **Dockerfile** as your trained model/data. Note that you must create public links for your trained model/data in Dockerfile.

# Object Detector Web App

The latest release of the [MAX Object Detector Web App](https://github.com/IBM/MAX-Object-Detector-Web-App)
is included in the Object Detector docker image.

When the model API server is running, the web app can be accessed at `http://localhost:5000/app`
and provides interactive visualization of the bounding boxes and their related labels returned by the model.

![Mini Web App Screenshot](docs/my-web-app.png)

repository: manhitv/MAX-object-detector

gha_language: Jupyter Notebook

repo_name: manhitv/MAX-object-detector