text:
QUIC datagram extensions

Hi,
Is there any intention/plan of supporting the current draft of datagram extensions as defined by https://tools.ietf.org/html/draft-ietf-quic-datagram-00 ?
In case this is not in the plans, would such a contribution be welcome or is it considered out of scope ?

I'd be interested in being able to use this.

I have a separate fork of quiche with rough DATAGRAM support.
The implementation is pretty straightforward, the trickier part is getting the API correct.
Now that the DATAGRAM extension has been adopted by the QUIC WG there is a stronger case for looking at this more seriously. Having people interested in using it makes a better case for getting feedback and coverage of the code.

Happy to help iterate on the API.

I did a quick rebase of LPardue's forked branch on top of master (https://github.com/xanathar/quiche/commits/datagrams-0.3.0).
This is the current API I extracted diffing the files (as currently implemented, of course):
    // In lib.rs:
    pub fn Config::set_max_datagram_frame_size(&mut self, v: u64)
    pub fn Connection::dgram_send(&mut self, buf: &[u8]) -> Result<()>
    pub fn Connection::dgram_recv(&mut self) -> Result<Vec<u8>>

    // In webtransport/mod.rs:
    pub enum Error
    pub const QUICTRANSPORT_ALPN: &[u8]
    pub type Result<T>
    pub fn QuicTransport::with_transport(conn: &mut super::Connection, origin: &str, path: &str) -> Result<QuicTransport>
    pub fn QuicTransport::dgram_send(&mut self, conn: &mut super::Connection, buf: &[u8]) -> Result<()>

    // In h3/ffi.rs:
    #[no_mangle] pub extern fn quiche_h3_datagram_event_type(ev: &h3::DatagramEvent) -> u32
    pub enum DatagramEvent
    pub fn dgram_send(&mut self, conn: &mut super::Connection, flow_id: u64, buf: &[u8]) -> Result<()>
    pub fn poll_dgram(&mut self, conn: &mut super::Connection) -> Result<(u64, DatagramEvent)>
    pub fn process_dgram(&mut self, conn: &mut super::Connection) -> Result<(u64, DatagramEvent)>

I'm currently focusing on the quic part (i.e. no http3 things).
The Connection::dgram_recv API has a signature which is radically different from Connection::stream_recv, but something like pub fn dgram_recv(&mut self, out: &mut [u8]) -> Result<(usize, bool)> would require an extra copy of the buffer (but maybe it would allow an easier interop with C).
As far as C interop is concerned, I drafted a commit with a working C interface to the datagram API: https://github.com/xanathar/quiche/commit/1dbb0b0a3e3c043fe403ae636fa65516b1262ed6 ; feedbacks are welcome (specially around quiche_conn_dgram_free).
One question on the functional aspect: in theory the datagram extension draft says datagrams must be subject to the flow control which in quiche is represented by the send api limits (or whatever is returned by stream_capacity). Does this mean that dgram_send should be limited by the application ? if so, should we expose something more ?

Thanks for looking at this. Ideally the datagram work should be broken into three pieces that reflect the maturity of the standards process: QUIC datagram, H3 datagram and WebTransport. WebTransport is different enough that I should spin it off into a separate PR and we can ignore it for now.
stream_recv allows the caller to read as much or as little as they want. IIRC I decided to make the dgram_recv signature different because it doesn't make sense to read a partial datagram. Given the pains you've had to go through to get this working with the C API I'm not opposed to changing dgram_recv, it would just need some checks to ensure the output buffer is large enough for the received datagram. Providing a large enough buffer is pretty easy because the receiving endpoint set's its own max_datagram_frame_size TP.

I don't know. On one side it would allow for cleaner interop, on the other if one is using datagrams is probably for performance sensitive stuff, and saving a copy could be worth, specially considering that, with datagrams coming out of order, duplicated etc. it's likely that the application cannot specify the final location but needs yet another copy to reassemble the message in any case. I'm seriously on the fence on this.
As an aside, I added some datagram calls to a C++ application I had which is also using a stream and sometimes it stops working; I'm debugging it right now. 99% is some mistake on my side, but it seems it's spinning in while let Some(len) = self.dgram_queue.peek_writable(). Will keep you updated.

I've reasoned a while on the interface which datagrams extensions could have to the application code, and this are a couple of my proposals, please provide feedback.
Scope
This proposal works only around the QUIC part. I have not considered (yet) the H3 part of the problem, nor the WebTransport, to start from the foundations.
Also, I tried to do an effort towards having an API which most closely matches the other APIs in quiche, if no real drawback comes from this (there are trade-offs to be considered).
Rationales
I took into account three points of rationale from days of testing this in (private) real-world prototypes.
First is having some control on the outgoing queue (that is the queue of packets to be sent). This is to handle several scenarios where datagrams which were meant to be sent asap, now have lost their "value"; for example a typical case is an application discarding old stale datagrams when a new datagram of the same type is appended to the queue, or prioritizing datagrams.
Typical cases here are previous video frames after too much time has passed, videogame state snapshots, audio packets after a given delta of time has passed (if no speed-modulation is done) or really any data which is either cumulative and idempotent or has a maximum useful age.
Second, a topic raised in this issue and https://github.com/LPardue/quiche/pull/1 was whether it was best to keep the dgram_recv interface as it was in LPardue's branch (dgram_recv(&mut self) -> Result<Vec<u8>>) or it was better to have it in a form more similar to stream_recv which also allows for an easier to use interface to C at the expense of an extra memory copy (though not allocation) at every call (dgram_recv(&mut self, out: &mut [u8])). Details can be found at https://github.com/LPardue/quiche/pull/1, but the long story short is that there seems to be no or negligible advantages in having one less copy of data, and the cleaner interface is a winner; if what found in that issue proves to be incorrect, it’s a matter of amending dgram_recv.
Third - minor - for naming uniformity with Config::set_max_datagram_frame_size, which cannot be renamed to ..dgram.. because it refers to a specific QUIC transport parameter, I renamed all the methods from dgram_something to datagram_something.
Proposal 1
This proposal is the one with the simplest interface. Everything stays the same as in LPardue's branch, except for minor details:

The ability to configure the size of the datagram queues (i.e. 2 config calls)
A datagram_purge_outgoing to allow applications to remove datagrams waiting to be sent, which are outdated for some reason.

The drawback of this approach, which is far cleaner than my second proposal, is that applications can easily purge outdated packets in the sending queue, but not reprioritize them (other then purging the queue temporarily, and re-adding them in the desired order). Still this can be extended, for example with a datagram_send_urgent or similar, in a second time, when and if it proves to be needed.
/// Sets the maximum size of the datagram sende queue
pub fn Config::set_datagram_send_queue_size(&mut self, size: u64) -> Result<()>;
/// Sets the maximum size of the datagram received queue
pub fn Config::set_datagram_recv_queue_size(&mut self, size: u64) -> Result<()>;
/// Sets the transport's max_datagram_frame_size
pub fn Config::set_max_datagram_frame_size(&mut self, v: u64);

/// Sends a datagram on a connection
pub fn Connection::datagram_send(&mut self, buf: &[u8]) -> Result<()>;
/// Receives a datagram from the connection
pub fn Connection::datagram_recv(&mut self, out: &mut [u8]) -> Result<usize>;
/// Iterates over the outgoing queue and purges datagrams matching the filter
pub fn Connection::datagram_purge_outgoing<F>(&mut self, filter: F) -> Result<()>
    where F: FnMut(&[u8]) -> bool;

Proposal 2
This proposal is the one with the most control over the sending queue. An object with the DatagramsOutgoingQueue trait can be passed by the application to customize the behavior of the sending queue to its preference.
/// An implementation may be passed by the application, otherwise the default one
/// will be used.
pub trait DatagramsOutgoingQueue
where
    Self: std::fmt::Debug,
{
    /// Adds a datagram to the outgoing queue
    pub fn push_datagram(&mut self, data: &[u8]) -> Result<()> ;
    /// Returns the size of the next outgoing datagram to be sent, or None.
    pub fn peek_datagram(&self) -> Option<usize>;
    /// Returns the next buffer to be sent (or None).
    pub fn pop_datagram(&mut self) -> Result<&[u8]>;
}

/// Sets the outgoing datagram queue to be used, the default one is used otherwise
pub fn Config::set_datagram_send_queue(&mut self, &queue: DatagramsOutgoingQueue);
/// Sets the maximum size of the datagram received queue
pub fn Config::set_datagram_recv_queue_size(&mut self, size: u64) -> Result<()>;
/// Sets the transport's max_datagram_frame_size
pub fn Config::set_max_datagram_frame_size(&mut self, v: u64);

/// Sends a datagram on a connection, queuing it to the current DatagramsOutgoingQueue
pub fn Connection::datagram_send(&mut self, buf: &[u8]) -> Result<()>;
/// Receives a datagram from the connection
pub fn Connection::datagram_recv(&mut self, out: &mut [u8]) -> Result<usize>;

As said, feedback is very welcome, as is any alternative, etc.

@xanathar proposal 2 is an interesting alternative. How do you see an application loop working with this? Something like:

conn.datagram_send("foo");
conn.datagram_send("bar");
conn.datagram_send("baz");
conn.send(...) which internally will get around to calling self.DatagramsOutgoingQueue.pop()

Do you imagine an ability to purge items in DatagramsOutgoingQueue, which may be public or private depending on need?

yes, proposal 2 is exactly how you described; the ability to purge items in DatagramsOutgoingQueue would be there, since the object with the DatagramsOutgoingQueue trait would be provided by the application itself (with a default implementation which doesn't allow it, for those who don't need that level of control).

authors: LPardue ctiller xanathar

repo: cloudflare/quiche


text:
update validation records/errors for custom_hostname and certificate_pack

resource/custom_hostname: validation tokens are now an array (`validation_records`) instead of a top level, but the only top level record that was previously here was for cname validation, txt/http/email were entirely missing.
resource/custom_hostname: also adds missing `validation_errors`, and `certificate_authority`
resource/certificate_pack: adds `validation_errors` and `validation_records` with same format as custom hostnames.

relies of lib behavior added in https://github.com/cloudflare/cloudflare-go/pull/796

@nickysemenza could you move the CHANGELOG entry to the file as the documentation mentions? that will allow it post merge to be picked up correctly.

acceptance tests are green
TF_ACC=1 go test $(go list ./...) -v -run "^TestAccCloudflareCustomHostname" -count 1 -parallel 1 -timeout 120m -parallel 1
?   	github.com/cloudflare/terraform-provider-cloudflare	[no test files]
=== RUN   TestAccCloudflareCustomHostnameFallbackOrigin
--- PASS: TestAccCloudflareCustomHostnameFallbackOrigin (13.94s)
=== RUN   TestAccCloudflareCustomHostnameFallbackOriginUpdate
--- PASS: TestAccCloudflareCustomHostnameFallbackOriginUpdate (23.16s)
=== RUN   TestAccCloudflareCustomHostname_Basic
=== PAUSE TestAccCloudflareCustomHostname_Basic
=== RUN   TestAccCloudflareCustomHostname_WithCustomOriginServer
=== PAUSE TestAccCloudflareCustomHostname_WithCustomOriginServer
=== RUN   TestAccCloudflareCustomHostname_WithHTTPValidation
=== PAUSE TestAccCloudflareCustomHostname_WithHTTPValidation
=== RUN   TestAccCloudflareCustomHostname_WithCustomSSLSettings
=== PAUSE TestAccCloudflareCustomHostname_WithCustomSSLSettings
=== RUN   TestAccCloudflareCustomHostname_Update
=== PAUSE TestAccCloudflareCustomHostname_Update
=== RUN   TestAccCloudflareCustomHostname_WithNoSSL
=== PAUSE TestAccCloudflareCustomHostname_WithNoSSL
=== RUN   TestAccCloudflareCustomHostname_UpdatingZoneForcesNewResource
=== PAUSE TestAccCloudflareCustomHostname_UpdatingZoneForcesNewResource
=== RUN   TestAccCloudflareCustomHostname_Import
=== PAUSE TestAccCloudflareCustomHostname_Import
=== CONT  TestAccCloudflareCustomHostname_Basic
--- PASS: TestAccCloudflareCustomHostname_Basic (10.22s)
=== CONT  TestAccCloudflareCustomHostname_Update
--- PASS: TestAccCloudflareCustomHostname_Update (21.45s)
=== CONT  TestAccCloudflareCustomHostname_Import
--- PASS: TestAccCloudflareCustomHostname_Import (14.20s)
=== CONT  TestAccCloudflareCustomHostname_UpdatingZoneForcesNewResource
--- PASS: TestAccCloudflareCustomHostname_UpdatingZoneForcesNewResource (19.54s)
=== CONT  TestAccCloudflareCustomHostname_WithNoSSL
--- PASS: TestAccCloudflareCustomHostname_WithNoSSL (10.91s)
=== CONT  TestAccCloudflareCustomHostname_WithHTTPValidation
--- PASS: TestAccCloudflareCustomHostname_WithHTTPValidation (11.00s)
=== CONT  TestAccCloudflareCustomHostname_WithCustomSSLSettings
--- PASS: TestAccCloudflareCustomHostname_WithCustomSSLSettings (10.29s)
=== CONT  TestAccCloudflareCustomHostname_WithCustomOriginServer
--- PASS: TestAccCloudflareCustomHostname_WithCustomOriginServer (10.79s)
PASS
ok  	github.com/cloudflare/terraform-provider-cloudflare/cloudflare	146.054s
?   	github.com/cloudflare/terraform-provider-cloudflare/tools/cmd/changelog-check	[no test files]
?   	github.com/cloudflare/terraform-provider-cloudflare/version	[no test files]

source: gharchive/pull-request

authors: jacobbednarz nickysemenza

license_type: permissive

license_source: github-api


text:
Issue 1840 Add custom_hostname wait_for_active_status

As shown in https://github.com/cloudflare/terraform-provider-cloudflare/issues/1840, it can be problematic to create required validation records in the same terraform apply run because the custom_hostname resource completes creation before the required validation records are present on the resource.
This pull adds a wait_for_active_status flag similar to the flag introduced in https://github.com/cloudflare/terraform-provider-cloudflare/pull/1567.
I was NOT able to run the acceptance tests because I do not have a suitable Cloudflare account to do so. However I did test this with my currently blocked configuration and it resolved the issues I was seeing.

i've gone back and had a look at the initial issue however i don't think this actually  addresses the problem raised.
in the initial ticket, ownership_verification and ownership_verification_http are both set from the initial creation call however, the initial issue is trying to use the ssl.validation_records object for validation which this PR will never check so i'm unsure how this PR is fixing your issue.
@nickysemenza are you able to confirm which config block should be checked for the manual validation records? perhaps the original issue is just using the wrong fields.

interesting. it seemed from my testing that the ssl.validation_records were set once the hostname hit active status. this PR worked well for me with my local testing. i'll attach a sample tf file that i was testing with. i'll admit i'm largely unfamiliar with the underlying cloudflare api so if there is a better way to accomplish this i'll take that up instead.
main.tf.txt
testing_results.txt

the SSL sub-object will get its validation_records set once it transitions from initializing->pending_validation (which, if the parent hostname passes validation on the first try, will likely happen around the same time as the hostname transitioning from pending -> active.  (The ssl validation records require a call to the certificate authority to happen in the background) wheras the custom hostname validation records are generated in-house).
So as for the issue described in #1840,  waiting until resource.cloudflare_custom_hostname.test.ssl.0.validation_records.0.txt_value has a value can be accomplished by waiting until ssl.status== "pending_validation" or something along those lines - perhaps wait_for_ssl_pending_validation would be more appropriate?
see https://developers.cloudflare.com/ssl/reference/certificate-statuses/ and https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/domain-support/hostname-verification/#verification-statuses for references on statuses

thanks for the info - i've adjusted the pr to reflect that input

acceptance tests are passing
TF_ACC=1 go test $(go list ./...) -v -run "^TestAccCloudflareCustomHostname_" -count 1 -parallel 1 -timeout 120m -parallel 1
?       github.com/cloudflare/terraform-provider-cloudflare     [no test files]
=== RUN   TestAccCloudflareCustomHostname_Basic
=== PAUSE TestAccCloudflareCustomHostname_Basic
=== RUN   TestAccCloudflareCustomHostname_WaitForActive
=== PAUSE TestAccCloudflareCustomHostname_WaitForActive
=== RUN   TestAccCloudflareCustomHostname_WithCustomOriginServer
=== PAUSE TestAccCloudflareCustomHostname_WithCustomOriginServer
=== RUN   TestAccCloudflareCustomHostname_WithHTTPValidation
=== PAUSE TestAccCloudflareCustomHostname_WithHTTPValidation
=== RUN   TestAccCloudflareCustomHostname_WithCustomSSLSettings
=== PAUSE TestAccCloudflareCustomHostname_WithCustomSSLSettings
=== RUN   TestAccCloudflareCustomHostname_Update
=== PAUSE TestAccCloudflareCustomHostname_Update
=== RUN   TestAccCloudflareCustomHostname_WithNoSSL
=== PAUSE TestAccCloudflareCustomHostname_WithNoSSL
=== RUN   TestAccCloudflareCustomHostname_UpdatingZoneForcesNewResource
=== PAUSE TestAccCloudflareCustomHostname_UpdatingZoneForcesNewResource
=== RUN   TestAccCloudflareCustomHostname_Import
=== PAUSE TestAccCloudflareCustomHostname_Import
=== CONT  TestAccCloudflareCustomHostname_Basic
--- PASS: TestAccCloudflareCustomHostname_Basic (8.25s)
=== CONT  TestAccCloudflareCustomHostname_Update
--- PASS: TestAccCloudflareCustomHostname_Update (14.25s)
=== CONT  TestAccCloudflareCustomHostname_Import
--- PASS: TestAccCloudflareCustomHostname_Import (10.16s)
=== CONT  TestAccCloudflareCustomHostname_UpdatingZoneForcesNewResource
--- PASS: TestAccCloudflareCustomHostname_UpdatingZoneForcesNewResource (15.28s)
=== CONT  TestAccCloudflareCustomHostname_WithNoSSL
--- PASS: TestAccCloudflareCustomHostname_WithNoSSL (7.64s)
=== CONT  TestAccCloudflareCustomHostname_WithHTTPValidation
--- PASS: TestAccCloudflareCustomHostname_WithHTTPValidation (7.60s)
=== CONT  TestAccCloudflareCustomHostname_WithCustomSSLSettings
--- PASS: TestAccCloudflareCustomHostname_WithCustomSSLSettings (12.76s)
=== CONT  TestAccCloudflareCustomHostname_WithCustomOriginServer
--- PASS: TestAccCloudflareCustomHostname_WithCustomOriginServer (8.60s)
=== CONT  TestAccCloudflareCustomHostname_WaitForActive
--- PASS: TestAccCloudflareCustomHostname_WaitForActive (10.60s)
PASS
ok      github.com/cloudflare/terraform-provider-cloudflare/internal/provider   95.440s

thanks for this one @will-bluem-olo! we appreciate the effort you've put into this one -- you're first contribution at that! 🎉


text:
Small typo fix in comment

Deafult -> Default

@vlovich ... need you to ack the CLAAssistant here...

recheck

authors: jasnell vlovich

repo: cloudflare/workerd


text:
🐛 BUG: wrangler r2 object CLI

What version of Wrangler are you using?
2.5.0
What operating system are you using?
Mac
Describe the Bug
To reproduce:

Create a new r2 bucket called foobar
Create a README.md
Attempt to upload the README.md file to foobar with the following command:
wrangler r2 object put foobar/README.md -f ./README.md

❯ wrangler r2 object put foobar/README.md -f ./README.md
 ⛅ wrangler 2.5.0
-------------------
Creating object "README.md" in bucket "foobar".

✘ [ERROR] Failed to fetch /accounts/<account id>/r2/buckets/foobar/objects/README.md - 404: Not Found);

If you think this is a bug then please create an issue at https://github.com/cloudflare/wrangler2/issues/new/choose
Running this command outputs the following error:

Now I don't think this is a bug and is likely PEBKAC. Hopefully, someone can point me in the right direction, and I'll close this issue. But this is not the only time I've been frustrated by the Cloudflare developer experience. All that I want to do is copy a file from my local system to R2. The cli wasn't intuitive enough for me to guess--I assumed it would be similar to the cp command--but the -h was well done. After trying many variations of this command and still receiving similar errors, I gave up and went to the docs. I'm not using workers in any capacity, but I have to go to the workers help to get any information on wrangler, a little confusing, but maybe I'm an outlier here. I get to the commands section and see r2 bucket documentation. But nothing for r2 object. I am, again, frustrated. I try the official R2 documentation, also a little confusing going to multiple product pages. No examples using wrangler, just 3rd party libs. Hence, filing this bug.
I love what y'all are doing, and I like the direction Cloudflare is heading with its developer-focused products. Still, I've encountered many paper cuts, primarily in the fragmented documentation across multiple product umbrellas. I consider pages, workers, r2, images etc., all to be bleeding-edge products, and I constantly advocate for their use over more traditional software development patterns, but these issues make that more difficult.

Hi @lucasnad27, I'm so sorry you experienced this issue.
We'll update the wrangler command docs to document the wrangler r2 object commands, and I've raised with the team whether it still makes sense to keep Wrangler underneath Workers in the docs.

thanks @rozenmd Appreciate the quick response.
Should I keep this issue open until I see an update to the docs? Or close and re-open if I run into issues once those docs are available?

@lucasnad27 I'll make a PR into https://github.com/cloudflare/cloudflare-docs resolving the issue, which will automatically close this issue and the one I just filed in that repo (https://github.com/cloudflare/cloudflare-docs/issues/6894)

@lucasnad27 i think you're using the command correctly. Silly question though. Does the bucket foobar exist for you? If you email my GitHub username at cloudflare dot com with your account ID I can take a deeper look for you (just reference this GitHub issue for context).
Sorry for the frustration and hopefully we can get you unblocked.
As an alternative, there are other command-line tools out there that are more mature. Rclone in particular is quite popular.

No silly questions! :) foobar was a placeholder for a bucket created by my CF account.
However, I just tried reproducing the error using the same command I posted earlier (wrangler r2 object put foobar/README.md -f ./README.md) and it worked! I thought there might be a consistency issue with my last failed attempt, so I tried creating a new bucket (both from the CLI & UI)  and was able to upload the README.md file without issue 🤷
Thanks for the tip re: rclone. If I do anything substantive from the CLI, I'll keep that in mind.

source: gharchive/issue

authors: lucasnad27 rozenmd vlovich


text:
Config options for metric prefix and director name.

The nozzle currently places all the metrics it derives from firehose
data in the root of Stackdriver's custom metric namespace. This means
there's a relatively large chance that these names could collide with
others that were not created by the nozzle. To mitigate this, a config
option "metric_path_prefix" (that defaults to "firehose") is added.
After this commit, Stackdriver metric names will be of the form:
custom.googleapis.com/PREFIX/origin.Name
custom.googleapis.com/firehose/gorouter.total_requests

Running multiple PCF instances in the same GCP project will result in
metrics from all instances being confused with each other. Since the
nozzle runs on BOSH, another config option "bosh_director_name" (that
defaults to "cf") has been added. This sets the value of a static
"director" label added to every metric exported by the nozzle. Setting
this to different values for each PCF instance in a project (e.g. the
GCP region, if running one PCF instance per region) allows PCF metrics
to be distinguished from one another.

This change is

I'll rebase this onto develop after PR #136 is in, which ought to make it easier to review. I wanted to base this PR off that one because it made logical sense to do so, but I'm not github-savvy enough to know how to exclude the first commit from the second PR, if such a thing is even possible.

Review status: 0 of 10 files reviewed at latest revision, 1 unresolved discussion.

src/stackdriver-nozzle/config/config.go, line 69 at r1 (raw file):

	MetricsBufferSize     int    `envconfig:"metrics_buffer_size" default:"200"`
	MetricPathPrefix      string `envconfig:"metric_path_prefix" default:"firehose"`
	BoshDirectorName      string `envconfig:"bosh_director_name" default:"cf"`

What I actually had in mind is slightly more flexible: instead of having a single hard-coded label with user-supplied value, what if we could just accept an arbitrary number of key/value pairs that are passed as labels for all metrics? This will allow users to attach other instance-specific metadata to their metrics. There is obviously a risk that providing too many labels will exceed 10 label limit, but this will be clearly visible in the logs (and we could document this as a caveat). What do you think?

Comments from Reviewable

Review status: 0 of 10 files reviewed at latest revision, 1 unresolved discussion.

src/stackdriver-nozzle/config/config.go, line 69 at r1 (raw file):
Previously, knyar (Anton Tolchanov) wrote…
What I actually had in mind is slightly more flexible: instead of having a single hard-coded label with user-supplied value, what if we could just accept an arbitrary number of key/value pairs that are passed as labels for all metrics? This will allow users to attach other instance-specific metadata to their metrics. There is obviously a risk that providing too many labels will exceed 10 label limit, but this will be clearly visible in the logs (and we could document this as a caveat). What do you think?

I did originally do that, but stepped back, because: why?
I don't see any value in attaching >1 label to all metrics from a PCF instance, because it should be possible to derive any other values you might want to for that instance based on the one label. (I guess SD doesn't quite have JoinWithLiteralTable yet, but that's what I'm thinking of.)
This also enforces the label name to be "director" which is what the PCF folks want to standardise on as the label to differentiate between PCF instances, according to David Laing. Only allowing users to change the value enforces naming consistency.
Then there's the risk of exceeding the 10 label limit. There's some headroom there but I am not a fan of leaving guns footwards like that...

Comments from Reviewable

@fluffle - I rebased your changed on develop and force pushed. I don't know if that's proper etiquette or not

Can you also update: tile.yml.erb, jobs/stackdriver-nozzle/spec with the new fields?

Reviewed 7 of 10 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Review status: all files reviewed at latest revision, 1 unresolved discussion, all commit checks successful.

jobs/stackdriver-nozzle/templates/stackdriver-nozzle-ctl.erb, line 38 at r2 (raw file):

    export METRICS_BUFFER_SIZE=<%= p('nozzle.metrics_buffer_size', '200') %>
    export METRIC_PATH_PREFIX=<%= p('nozzle.metric_path_prefix', 'firehose') %>
    export BOSH_DIRECTOR_NAME=<%= p('nozzle.bosh_director_name', 'cf') %>

Can you also update: tile.yml.erb, jobs/stackdriver-nozzle/spec with the new fields?
(reposting as comment so it can be resolved)

Comments from Reviewable

I had to force-push updates anyway. I think @knyar's comments may have been on changes that were in the commit from #136, not sure. Hope I've got everything now!

Review status: 7 of 9 files reviewed at latest revision, 1 unresolved discussion.

jobs/stackdriver-nozzle/templates/stackdriver-nozzle-ctl.erb, line 38 at r2 (raw file):
Previously, johnsonj (Jeff Johnson) wrote…
Can you also update: tile.yml.erb, jobs/stackdriver-nozzle/spec with the new fields?
(reposting as comment so it can be resolved)

Aha, thank you. I should have done a recursive grep to see if there was more wiring to be connected up :-)

Comments from Reviewable

Reviewed 3 of 3 files at r3.
Review status: all files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

jobs/stackdriver-nozzle/templates/stackdriver-nozzle-ctl.erb, line 38 at r2 (raw file):
Previously, fluffle (Alex Bee) wrote…
Aha, thank you. I should have done a recursive grep to see if there was more wiring to be connected up :-)

Thanks!

Comments from Reviewable

Reviewed 8 of 8 files at r4.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

authors: fluffle johnsonj knyar

license_source: bigquery


text:
support global cpi configuration for tags

to allow tagging of all vms with specific set of tags to enable setting security groups. global tags would be added on top of tags specified via env arg in create_vm. wdyt about google.default_tags: [tag1, tag2]?
cc @evandbrown @dsboulder

@dsboulder @mrdavidlaing do default_tags give you capabilities that 'tag with job name' doesn't?
Otherwise I'm fine with this and happy to add if it's useful.

@evandbrown this will be useful for setting custom tags director wide (including director), e.g. staging-blah. this global cpi configuration (not in vm cloud properties) will enforce tag setting across all machines.

authors: cppforlife evandbrown


text:
Tests fail occasionally with "No mapping between account names and security IDs was done."

The LocalPrincipalManager tests fail occasionally with the above error.
I believe it is related to some eventual consistency in Windows with creating a new user, and then trying to add that user to a security group.  The error suggests that the failure was in mapping a username to a SID.
We should consider polling (in the code) to ensure that the user exists and can be mapped to a SID, before continuing and trying to use the new user.

Here is an example stack trace:
Test Name:    IronFoundry.Container.Utilities.LocalPrincipalManagerTests.AddedUserAppearsInWardenGroup
Test FullName:    IronFoundry.Container.Utilities.LocalPrincipalManagerTests.AddedUserAppearsInWardenGroup
Test Source:    c:\git\if\if_warden\IronFoundry.Container.Test\Utilities\LocalPrincipalManagerTests.cs : line 62
Test Outcome:    Failed
Test Duration:    0:00:00.164

Result Message:    System.Runtime.InteropServices.COMException : No mapping between account names and security IDs was done.
Result StackTrace:
at System.DirectoryServices.PropertyValueCollection.PopulateList()
  at System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName)
  at System.DirectoryServices.PropertyCollection.get_Item(String propertyName)
  at System.DirectoryServices.AccountManagement.QbeMatcher.Matches(DirectoryEntry de)
  at System.DirectoryServices.AccountManagement.SAMQuerySet.MoveNext()
  at System.DirectoryServices.AccountManagement.FindResultEnumerator`1.MoveNext()
  at System.DirectoryServices.AccountManagement.PrincipalSearcher.FindOne()
  at IronFoundry.Container.Utilities.LocalPrincipalManager.AddUserToGroup(PrincipalContext context, String groupName, UserPrincipal user) in c:\git\if\if_warden\IronFoundry.Container.Shared\Utilities\LocalPrincipalManager.cs:line 151
  at IronFoundry.Container.Utilities.LocalPrincipalManager.InnerCreateUser(String userName) in c:\git\if\if_warden\IronFoundry.Container.Shared\Utilities\LocalPrincipalManager.cs:line 136
  at IronFoundry.Container.Utilities.LocalPrincipalManager.CreateUser(String userName) in c:\git\if\if_warden\IronFoundry.Container.Shared\Utilities\LocalPrincipalManager.cs:line 59
  at IronFoundry.Container.Utilities.LocalPrincipalManagerTests.AddedUserAppearsInWardenGroup() in c:\git\if\if_warden\IronFoundry.Container.Test\Utilities\LocalPrincipalManagerTests.cs:line 63

Error Code for this is: 0x80070534

authors: brannon mosoto


text:
Do not fail apply-specs if addons-spec is empty

Is your feature request related to a problem? Please describe.
kubectl fails when you apply a manifest that does not contain any objects:
$ echo "---" | kubectl apply -f -
error: no objects passed to apply

If a user provides an empty manifest, for instance --- or whitespace. That will fail the apply-specs errand. We ran into this because OpsMan can not concatenate two values without some sort of additional characters. Additionally, if a user provides --- it will fail which is not obvious.
Describe the solution you'd like
When applying specs one of three things can be done:

Parse the yaml first and see if contains data. There are already some empty value checks being done here: https://github.com/cloudfoundry-incubator/kubo-release/blob/42f962bb594aa3092094393560cdd38e571af698/jobs/apply-specs/spec
Apply the specs and if the error matches "error: no objects passed to apply" do not fail the errand.
Just trim whitespace from both sides of the document before doing the empty check. This would solve our issue but users that provide --- would still fail the errand.

Describe alternatives you've considered
We spent a day trying to get OpsMan to craft either null or "" when concatenating two empty strings. We were not able to find a way to accomplish this. Our workaround is to always have an namespace object created so that the job doesn't fail for this reason.
Additional context
Pretty straight forward issue.

Thanks for highlighting this @jasonkeene
On first glance, we think the current behaviour is appropriate.  The error highlights to the user that they have passed malformed/empty spec to CFCR/kubectl, and that they would probably want to investigate as to why they are passing empty files.
I'm going to close this for now, but feel free to discuss further in the comments if you wish.
cc @karampok

Fair enough. We've worked around this on our end by always appending a namespace.

authors: iainsproat jasonkeene

repo: cloudfoundry-incubator/kubo-release


text:
Fix npm audit vulnerabilities

result of npm audit fix and manually removing stratos-merge-dirs

We should park this until we upgrade to Angular 8. The issue might come out in the wash.

Angular upgrade #3920

@KlapTrap This was raised as a concern by the community. Is there any reason why this shouldn't be merged other than waiting for Angular 8?

@richard-cox @KlapTrap I think we should get this in - but I don't understand the changes to the package lock file.
Many dependencies have changed from being explicitly pinned, e.g. "1.9.3" to "^1.9.3" - it would be good to understand why, so we don't have this flip-flopping with PRs.

I agree that we should fix this, I was just going to wait for the angular 8 upgrade. ng updatge will get all of the relevant dependancies to the correct & compatible versions.
Having said that, I've done some of the angular 8 migration here; https://github.com/cloudfoundry-incubator/stratos/pull/3950 and It's going to take a while to manually migrate some of the code. So, with that in mind, I don't mind this being merged once everyone is happy.

authors: KlapTrap nwmac richard-cox

repo: cloudfoundry-incubator/stratos


text:
registry hangs and is unresponsive: bosh deploy fails with execution expired

We saw recently a few deployments failing with the error of execution expired during writing the settings for a VM into the registry. The registry stopped responding at all, there was nothing in the logs.
Even when being on the Director itself, calling the registry didn't work. Something like
# curl  http://localhost:25777/instances/bla/settings

should fail with an error saying instance 'bla' not found, but just hangs until it runs into a read timeout.
So we attached a gdb and looked at the backtrace, seeing that excon couldn't open the ssl_socket and blocked forever in the rescue. Note that the documentation of IO.select states this piece of code as an explicit example on how to implement a blocking read
The gdb stacktracke:
(gdb) call (void) rb_backtrace()
	from /var/vcap/packages/registry/bin/bosh-registry:16:in `<main>'
	from /var/vcap/packages/registry/bin/bosh-registry:16:in `load'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/bosh-registry-1.3202.0/bin/bosh-registry:28:in `<top (required)>'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/bosh-registry-1.3202.0/lib/bosh/registry/runner.rb:18:in `run'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/bosh-registry-1.3202.0/lib/bosh/registry/runner.rb:34:in `start_http_server'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/thin-1.5.1/lib/thin/server.rb:159:in `start'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/thin-1.5.1/lib/thin/backends/base.rb:63:in `start'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in `run'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in `run_machine'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/thin-1.5.1/lib/thin/connection.rb:39:in `receive_data'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/thin-1.5.1/lib/thin/connection.rb:54:in `process'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/thin-1.5.1/lib/thin/connection.rb:79:in `pre_process'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/thin-1.5.1/lib/thin/connection.rb:79:in `catch'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/thin-1.5.1/lib/thin/connection.rb:81:in `block in pre_process'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/rack-1.6.4/lib/rack/urlmap.rb:50:in `call'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/rack-1.6.4/lib/rack/urlmap.rb:50:in `each'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/rack-1.6.4/lib/rack/urlmap.rb:66:in `block in call'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:2021:in `call'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:181:in `call'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/show_exceptions.rb:21:in `call'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/rack-1.6.4/lib/rack/head.rb:13:in `call'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/rack-1.6.4/lib/rack/nulllogger.rb:9:in `call'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/rack-protection-1.5.3/lib/rack/protection/frame_options.rb:31:in `call'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49:in `call'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/rack-protection-1.5.3/lib/rack/protection/base.rb:49:in `call'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/rack-protection-1.5.3/lib/rack/protection/json_csrf.rb:18:in `call'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/rack-protection-1.5.3/lib/rack/protection/path_traversal.rb:16:in `call'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/rack-protection-1.5.3/lib/rack/protection/xss_header.rb:18:in `call'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:894:in `call'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:906:in `call!'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1066:in `invoke'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1066:in `catch'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1066:in `block in invoke'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:906:in `block in call!'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1081:in `dispatch!'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1066:in `invoke'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1066:in `catch'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1066:in `block in invoke'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1084:in `block in dispatch!'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:971:in `route!'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:971:in `each'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:972:in `block in route!'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1012:in `process_route'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1012:in `catch'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1014:in `block in process_route'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:974:in `block (2 levels) in route!'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:993:in `route_eval'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:974:in `block (3 levels) in route!'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:974:in `[]'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1610:in `block in compile!'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/sinatra-1.4.6/lib/sinatra/base.rb:1610:in `call'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/bosh-registry-1.3202.0/lib/bosh/registry/api_controller.rb:22:in `block in <class:ApiController>'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/bosh-registry-1.3202.0/lib/bosh/registry/instance_manager.rb:29:in `read_settings'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/bosh-registry-1.3202.0/lib/bosh/registry/instance_manager.rb:54:in `check_instance_ips'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/bosh-registry-1.3202.0/lib/bosh/registry/instance_manager/openstack.rb:79:in `instance_ips'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/fog-1.34.0/lib/fog/openstack/models/compute/server.rb:151:in `private_ip_addresses'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/fog-1.34.0/lib/fog/openstack/models/compute/server.rb:127:in `floating_ip_addresses'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/fog-1.34.0/lib/fog/openstack/models/compute/server.rb:109:in `all_addresses'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/fog-1.34.0/lib/fog/openstack/requests/compute/list_all_addresses.rb:6:in `list_all_addresses'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/fog-1.34.0/lib/fog/openstack/compute.rb:355:in `request'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/fog-core-1.32.1/lib/fog/core/connection.rb:81:in `request'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/excon-0.45.4/lib/excon/connection.rb:233:in `request'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/excon-0.45.4/lib/excon/middlewares/base.rb:15:in `request_call'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/excon-0.45.4/lib/excon/middlewares/base.rb:15:in `request_call'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/excon-0.45.4/lib/excon/middlewares/base.rb:15:in `request_call'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/excon-0.45.4/lib/excon/middlewares/instrumentor.rb:22:in `request_call'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/excon-0.45.4/lib/excon/middlewares/mock.rb:47:in `request_call'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/excon-0.45.4/lib/excon/connection.rb:106:in `request_call'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/excon-0.45.4/lib/excon/connection.rb:387:in `socket'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/excon-0.45.4/lib/excon/connection.rb:387:in `new'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/excon-0.45.4/lib/excon/ssl_socket.rb:119:in `initialize'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/excon-0.45.4/lib/excon/ssl_socket.rb:122:in `rescue in initialize'
	from /var/vcap/packages/registry/gem_home/ruby/2.1.0/gems/excon-0.45.4/lib/excon/ssl_socket.rb:122:in `select'

This is an acepted  bug in excon 0.45.4 and has been fixed by adding a timeout to IO.select in 0.49.
fog-core is already updated to consume excon 0.49. We're now waiting for fog and fog-openstack to be updated to consume fog-core 1.38.0.
While this prevents excon from blocking forever, it might be a good idea to have a detailed look at the registry on what else could be done to prevent one hanging call blocking the entire registry for everyone.

Updating fog and excon sounds ok.

I've created https://www.pivotaltracker.com/story/show/119363951 to bump fog in bosh-registry.

Fixed with bosh 257.14

authors: cppforlife voelzmo

repo: cloudfoundry/bosh


text:
Please complete the Cloudfoundry Component Log Timestamp Audit - as per: CF-RFC#030

Hi There!
In an effort to assure all CF components use a consistent logging timestamp as per CF-RFC#030, I'm submitting this issue requesting a little action from y'all on this x-component-team effort.
First
Please complete this audit as soon as possible.

this tracker story template includes additional information and tools to aid in completing the audit.

Second
If additional work is required to meet the requirements outlined in CF-RFC#030 please create, and take action to address, github issue(s) describing the work required to meet those requirements.
Thanks so much!
The CF-RFC#030 Authors (Josh Collins and Amelia Downs)

@heyjcollins
I asked the editor access to the audit spreadsheet.
By the way note that for the postgres-release we are only talking about bosh logs (pre-start and monit). PostgreSQL is a third-party app and its log are only configurable through the log_line_prefix parameter.

I've completed the audit and opened a story in PIvotal Tracker to address the requirement.

authors: heyjcollins valeriap

repo: cloudfoundry/postgres-release


text:
Docker/kubernetes deployment of UAA

How are you deploying the UAA?
I am wanting to deploy the UAA

other (please explain)
I want to be able to deploy UAA using docker (for me on kubernetes, but even a docker container would be fine). There are a few third-party images that people have build, but it would be ideal if we could have an official docker image

@agentgonzo
step 1  generate docker image
root@k8s:~/workspace/uaa# export DOCKER_REPO_URL=index.tenxcloud.com
root@k8s:~/workspace/uaa# export DOCKER_REPO_USER=username
root@k8s:~/workspace/uaa# export MAINTAINER_EMAIL=someone@company.com

root@k8s:~/workspace/uaa# ./gradlew -x javadocJar -x sourceJar  clean buildImage
BUILD SUCCESSFUL in 52s
38 actionable tasks: 38 executed
Task timings:
    974ms  :cloudfoundry-identity-model:compileJava
  15024ms  :cloudfoundry-identity-server:compileJava
    706ms  :cloudfoundry-identity-statsd:compileJava
    960ms  :cloudfoundry-identity-statsd:war
   7541ms  :cloudfoundry-identity-uaa:war
   3267ms  :cloudfoundry-identity-samples:cloudfoundry-identity-api:war
   3361ms  :cloudfoundry-identity-samples:cloudfoundry-identity-app:war
  15854ms  :buildImage
Test timings:

step 2 run uaa in docker
root@k8s:~#  docker run -p 8080:8080 --name uaa -d --restart=always \
       -v /opt/uaa.yml:/uaa/uaa.yml                   \
       index.tenxcloud.com/username/uaa:4.14.0

@JoshuaAndrew
does it mean that some 3rd party docker image belonging to index.tenxcloud.com is used?

@w7089
DOCKER_REPO_URL  can by any  docker image repo, It happened that I used index.tenxcloud.com here

But there's no official docker repository of cloud foundry where image of uaa can be downloaded from, correct?

@w7089 The gradle task that builds a docker image (./gradlew -x javadocJar -x sourceJar  clean buildImage) was contributed by the community. The intent was for development usage only (it hardcodes private keys etc). However we have discovered that it has been used in the wild for production purposes. This plugin is considered by the team deprecated. We do not test this image in our pipeline, and thus we are not sure if it works. We have a plan to remove this plugin.
To answer your initial question, we do not have an official docker image published to run uaa.
We do have a recommended way to run the uaa which is via its bosh release. bosh is a way to run software in different IaaSes (AWS, GCP, Vsphere, Docker etc). We would recommend to run uaa using bosh targeting docker as your Iaas.
If this approach interests you, then you can look at our uaa acceptance tests that runs uaa inside docker and runs tests against that deployment. This is the bosh manifest that we use in our bosh docker deployment.
A quick way to create a bosh that targets a docker host would be to follow this test script. To target a docker host update https://github.com/cppforlife/bosh-docker-cpi-release/blob/master/tests/run.sh#L56

authors: DennisDenuto JoshuaAndrew agentgonzo w7089

repo: cloudfoundry/uaa


text:
Add table of contents to MD files

A lot of the markdown files are quite lengthy. It is nice to have a ToC to get an overview of what is in it. I used doctoc to generate them.
Not sure if this the way the project wants to go, but it would be nice to have auto-generated ToCs.

Coverage decreased (-0.09%) to 84.966% when pulling 6d5aefd871c7d3a78823cf949750bdccd5deacbc on pradtke:doctoc into 7267d5553a633e9948250fc70772ec03e604fa18 on cloudfoundry:develop.

We have plans to consolidate all docs under doc.cloudfoundry.org. This in the in the process of getting reviewed and will be published soon

authors: coveralls pradtke sreetummidi


text:
Question: Any way to edit global variables dynamically

Say i have a less file with a bunch of global variables (@variable...) would it be possible for me to change their value using JavaScript (after the page is loaded)?
Thanks!

Hi,
I needed a similar solution described in the beginning of this thread.
For this, I wrote a tiny function that solved it for me.
I forked Less today - check it out:
https://github.com/hbi99/less.js/blob/master/dist/less-1.1.6.js
Worth mentioning; this is a fast solution in order to focus on my primary project - therefore, it can most likely be implemented more gracefully than my version. The function accepts a JSON object and variables declared in that object will override existing variables. Finally, the function does not cause new requests to the server.
Anywho, this is how it can be used:
Sample LESS:
@bgColor: black;
@textColor: yellow;
body {background: @bgColor; color: @textColor;}
From JS:
less.modifyVars({
'@bgColor': 'blue',
'@textColor': 'red'
});

Why not just dynamically create a LESS file with variable overrides and recompile?

@matthewdl - actually, the loaded LESS file(s) are stored in a variable called "session_cache". All "new" less-variables pushed in via "modifyVars" are appended to "session_cache" - thereby treated as a new less file and re-renders new CSS.
@Loda - the answer to your question is yes. See my answer to mathewdl - all variables passed in via "modifyVars" will be evaluated as if they were part of the LESS file, just know that the new vars will be appended at the end of the LESS files.
Example:
less.addVars({'@color': 'darken(#F00, 10%)'});
Finally, I would like to inform about two more things;

Any "@import" lines will be removed from the loaded LESS file(s) when stored in "session_cache". This is a good thing (IMHO) - all LESS files will be concatinated and stored in the variable "session_cache". No need to re-import them.

If one utilizes animations with transforms - using this function might result in - depending on how you utilize transforms, result in bad or good visual effect.

Good effect = if the colors animates, it will result in fading-effect.
Bad effect = if one have animations with movement, scaling, etc, which are triggered "onload" - animations will reset and animate from the start.

authors: elfassy hbi99 matthewdl


text:
RangeError (index): Invalid value: Only valid value is 0: 1 on Pixel 5 phone

When I run my app on Google Pixel 5 (API 32) (both device and emulator) the following throws error:
CldImg cldimg = CloudinaryObject.fromCloudName(cloudName: 'somename').image('someId');
print(cldimg); // throws: RangeError (index): Invalid value: Only valid value is 0: 1

On other phones everything works.
flutter doctor:
[✓] Flutter (Channel stable, 3.13.9, on macOS 14.0 23A344 darwin-arm64 (Rosetta), locale en-KG)
    • Flutter version 3.13.9 on channel stable at /Users/temair/Programs/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision d211f42860 (6 weeks ago), 2023-10-25 13:42:25 -0700
    • Engine revision 0545f8705d
    • Dart version 3.1.5
    • DevTools version 2.25.0

[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.1)
    • Android SDK at /Users/temair/Library/Android/sdk
    • Platform android-33, build-tools 33.0.1
    • ANDROID_HOME = /Users/temair/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b829.9-10027231)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 15.0.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 15A507
    • CocoaPods version 1.14.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2022.3)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b829.9-10027231)

[✓] VS Code (version 1.84.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.76.0

[✓] Connected device (2 available)
    • macOS (desktop) • macos  • darwin-arm64   • macOS 14.0 23A344 darwin-arm64 (Rosetta)
    • Chrome (web)    • chrome • web-javascript • Google Chrome 119.0.6045.199
    ! Error: Browsing on the local area network for iPhone. Ensure the device is unlocked and attached with a cable or associated
      with the same local area network as this Mac.
      The device must be opted into Developer Mode to connect wirelessly. (code -27)

[✓] Network resources
    • All expected network resources are available.

• No issues found!

Hi @temirfe
Thank you for reporting the issue, we'll take a look ASAP.

Hi there @temirfe,
Currently, we are unable to replicate your issue. Is there any additional information you could provide that can help us reproduce your issue?

authors: PixelCook adimiz1 temirfe

license: MIT


text:
Turkish language and git-updater support

Hello @cloudpanel-io
For those who want to use varnish cache with cloudpanel from Turkey, I translated the plugin into Turkish and I have added the headers requested by the git-updater plugin.

Thanks a lot @mertcangokgoz

authors: cloudpanel-io mertcangokgoz

repo: cloudpanel-io/clp-wp-varnish-cache


text:
Fix YAML conversion with empty strings

YAML merge fails when the input variable is an empty string or nil.
Hey, thanks for this provider. We use it to do a merge of two Helm value files (example below) - one with a set of default values and one with user overrides/additions. In cases when user does not set any overriding values, the second input is empty (var.values).
Passing an empty string (or nil) to the inputs, causes the provider to crash. I'm attaching the panic log below.
data "utils_deep_merge_yaml" "values" {
  count = var.enabled ? 1 : 0
  input = [
    local.values,
    var.values
  ]
}

goroutine 34 [running]:
github.com/cloudposse/terraform-provider-utils/internal/convert.YAMLSliceOfInterfaceToSliceOfMaps(0xc000576660, 0x2, 0x2, 0xb49b80, 0xc000338408, 0xd4ad01, 0xc00033a7c0, 0xc03b6ee8763240ae)
        github.com/cloudposse/terraform-provider-utils/internal/convert/yaml.go:20 +0x1f4
github.com/cloudposse/terraform-provider-utils/internal/provider.dataSourceDeepMergeYAMLRead(0xd4ada8, 0xc0003346c0, 0xc000366300, 0x0, 0x0, 0xc000336a70, 0xc000375948, 0x40e0f8)
        github.com/cloudposse/terraform-provider-utils/internal/provider/data_source_deep_merge_yaml.go:40 +0x87
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).read(0xc0003dc0e0, 0xd4ad38, 0xc00033a7c0, 0xc000366300, 0x0, 0x0, 0x0, 0x0, 0x0)
        github.com/hashicorp/terraform-plugin-sdk/v2@v2.7.0/helper/schema/resource.go:347 +0x17f
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*Resource).ReadDataApply(0xc0003dc0e0, 0xd4ad38, 0xc00033a7c0, 0xc000576300, 0x0, 0x0, 0x0, 0xc000576300, 0x0, 0x0)
        github.com/hashicorp/terraform-plugin-sdk/v2@v2.7.0/helper/schema/resource.go:558 +0xfd
github.com/hashicorp/terraform-plugin-sdk/v2/helper/schema.(*GRPCProviderServer).ReadDataSource(0xc00000c0a8, 0xd4ad38, 0xc00033a7c0, 0xc000576140, 0xc00033a7c0, 0x40b965, 0xbfbf20)
        github.com/hashicorp/terraform-plugin-sdk/v2@v2.7.0/helper/schema/grpc_provider.go:1105 +0x4d6
github.com/hashicorp/terraform-plugin-go/tfprotov5/server.(*server).ReadDataSource(0xc0000b9ac0, 0xd4ade0, 0xc00033a7c0, 0xc0003480a0, 0xc0000b9ac0, 0xc0003461b0, 0xc00058aba0)
        github.com/hashicorp/terraform-plugin-go@v0.3.0/tfprotov5/server/server.go:247 +0xe5
github.com/hashicorp/terraform-plugin-go/tfprotov5/internal/tfplugin5._Provider_ReadDataSource_Handler(0xc28bc0, 0xc0000b9ac0, 0xd4ade0, 0xc0003461b0, 0xc0003344e0, 0x0, 0xd4ade0, 0xc0003461b0, 0xc000360300, 0x17a)
        github.com/hashicorp/terraform-plugin-go@v0.3.0/tfprotov5/internal/tfplugin5/tfplugin5_grpc.pb.go:416 +0x214
google.golang.org/grpc.(*Server).processUnaryRPC(0xc00025ae00, 0xd51b58, 0xc000131980, 0xc000352000, 0xc0002c67b0, 0x11576d0, 0x0, 0x0, 0x0)
        google.golang.org/grpc@v1.32.0/server.go:1194 +0x52b
google.golang.org/grpc.(*Server).handleStream(0xc00025ae00, 0xd51b58, 0xc000131980, 0xc000352000, 0x0)
        google.golang.org/grpc@v1.32.0/server.go:1517 +0xd0c
google.golang.org/grpc.(*Server).serveStreams.func1.2(0xc000116280, 0xc00025ae00, 0xd51b58, 0xc000131980, 0xc000352000)
        google.golang.org/grpc@v1.32.0/server.go:859 +0xab
created by google.golang.org/grpc.(*Server).serveStreams.func1
        google.golang.org/grpc@v1.32.0/server.go:857 +0x1fd

Error: The terraform-provider-utils_v0.12.0 plugin crashed!

This PR adds a switch to the YAML convert function, which asses the interface type before passing the input to the convert function. In case a non-string value is passed as input, the iteration in the inner loop is skipped.
TL;DR

provider crashed when empty string is passed as input
PR adds type assessment and accepts only string values

/test all

/test all

@nitrocode @jhosteny @RothAndrew could you take a look and review this?

I've never touched this repo so I'm not wanting to be the approver, but nothing is jumping out at me as a red flag

/test all

authors: RothAndrew martinhaus nitrocode

repo: cloudposse/terraform-provider-utils


text:
chore: release main

:robot: I have created a release beep boop
operator: 1.0.0
1.0.0 (2024-11-02)
Features

init (e8be0d4)

Bug Fixes

build (cc58b33)
build (6062759)
build (9d22dff)
build (0304c39)
deps: update all non-major dependencies (c508cb7)
deps: update k8s.io/utils digest to 49e7df5 (c2662a5)
goreleaser (3e1b24e)
release (f2c81ad)
release (6c5efaf)
renovate.json (a566540)
update release (92b145f)

helm: 1.0.0
1.0.0 (2024-11-02)
Features

init (e8be0d4)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

operator-v1.0.0
helm-v1.0.0
:sunflower:

repo: cloudscalerio/cloudscaler


text:
make README a little more workplace-friendly

This is a cool project, and I just wanted to make it a little more immediately shareable.

Hell is a good word.

Hey @bg46z. There is no a big reason to change this words but I'm happy to see your interest here.
If you want to help us with the documentation there are many work related that. Explained for example on issue #45 . Feel free to join us :)

authors: bg46z cloudson ryukinix

repo: cloudson/gitql

license: mit


text:
all: use spansql for parse DDL

WHAT
all: use spansql for parse DDL
WHY
Can parse include comment schema

@zchee Please fix the tests (now it can't be compiled...) 🙏

🙄
I'll fix and write test

@zchee Let me fix the test cases...

repo: cloudspannerecosystem/wrench


text:
Is there an existing issue for this?

[X] I have searched the existing issues

Description
Unable to load datasource templates. Details: Cannot invoke "org.pf4j.PluginWrapper.getPluginClassLoader()" because the return value of "org.pf4j.PluginManager.getPlugin(String)" is null.
查看产品或者创建产品时出错，

但是插件的jar已经在dist中了，不知道为什么
Steps To Reproduce
编辑应用
Public Sample App
No response
Environment
Deploy Preview
Issue video log
No response
Version
1.6.6

是不是跟着教程文档走的，可以查看下docs.pageplug.cn里面，有一个本地安装的教程，有个内容还没更新，切换到jdk17

我在内网部署启动时出现两种错误，麻烦您帮忙看看是为什么呢

repo: cloudtogo/pageplug


text:
How to create an OriginAccessIdentity for CloudFront

The only information I have on OAI is the following
class S3Origin(AWSProperty):
props = {
'OriginAccessIdentity': (basestring, False),
}
How can I create on for my CloudFront distribution?
Pointers appreciated.

Hi,
OriginAccessIdentify: (basestring, False) means that a string goes here, and that it's not required. I think you probably need to look at the amazon docs to tell what should go there. Based on the docs here it indicates that you put the CloudFront origin access identity here - so you want something like S3Origin(OriginAccessIdentity=)

It is not possible without using custom resources, it's a well known annoyance of cloudfront + cloudformation.
Here's a project of my own, that contains a Custom Resource for handling just that. Note that the lambda that powers it, is by no means perfect, it won't delete the OAI when it's not used, though adding that is easy, I don't want it to happen automatically.
generate_package_repository.zip

authors: RasmusWernerLarsen emayssat-ms lil-cain

repo: cloudtools/troposphere


text:
How I can change the default param from python

How I can pass other value from python to keyname_param?
I Have:
template = Template()

keyname_param = template.add_parameter(Parameter(
    "KeyName",
    Description="Name of an existing EC2 KeyPair to enable SSH "
                "access to the instance",
    Default="param",
    Type="String",
))

I'm not sure I understand your question. Do you want to add multiple Parameters? There are uses of Parameters in the example directory that might help.

Not,
I want to pass other value to key_param.
I have param as a default with value param
I'm calling my troposphere template like:
python template.py
When I calling a CloudFormation I can pass the vars to set my template.
How can I do this from troposphere?

@ismaelfernandezscmspain You wouldn't necessarily do it from within troposphere, you would pass it as a variable using boto3 or one of the other aws sdk's. Below is how you could do it using Boto3:
cfparams = [] cfparams.append({'ParameterKey' : 'KeyName', 'ParameterValue': <value you want to pass here or variable>, 'UsePreviousValue' : False )
and then in your create_stack function use 'Parameters=cfparams,'
That should do what you're asking.

👍 works it!
thanks!

Troposphere just generate a template FILE. Nothing else! You can change the default value in template generation process or (better) you call your template with a non-default parameter! You can accomplish the latter with boto or from the aws cli, i.e.
aws cloudformation create-stack --stack-name myteststack --template-body file:////home//local//test//sampletemplate.json --parameters ParameterKey=KeyPairName,ParameterValue=TestKey ParameterKey=SubnetIDs,ParameterValue=SubnetID1\,SubnetID2

authors: emayssat-ms glitchindustries ismaelfernandezscmspain markpeek


text:
Demo fails

I've followed the instructions to run the demo. After installing, I run "npm start" which seems to succeed, but then fails. Full output is below.
flutter-webrtc-server $ npm install
npm WARN deprecated babel-preset-es2015@6.24.1: 🙌  Thanks for using Babel: we recommend using babel-preset-env now: please read babeljs.io/env to update!

> fsevents@1.2.4 install /Users/Sites/webrtc/flutter-webrtc-server/node_modules/fsevents
> node install

[fsevents] Success: "/Users/Sites/webrtc/flutter-webrtc-server/node_modules/fsevents/lib/binding/Release/node-v59-darwin-x64/fse.node" is installed via remote

> jss@9.8.7 postinstall /Users/Sites/webrtc/flutter-webrtc-server/node_modules/jss
> node -e "console.log('\u001b[35m\u001b[1mLove JSS? You can now support us on open collective:\u001b[22m\u001b[39m\n > \u001b[34mhttps://opencollective.com/jss/donate\u001b[0m')"

Love JSS? You can now support us on open collective:
 > https://opencollective.com/jss/donate
npm notice created a lockfile as package-lock.json. You should commit this file.
added 1137 packages in 87.457s
flutter-webrtc-server $ npm start

> flutter-webrtc-web@1.0.0 start /Users/Sites/webrtc/flutter-webrtc-server
> npm-run-all --parallel run-server run-webpack-dev-server

> flutter-webrtc-web@1.0.0 run-server /Users/Sites/webrtc/flutter-webrtc-server
> node server/index.js

> flutter-webrtc-web@1.0.0 run-webpack-dev-server /Users/Sites/webrtc/flutter-webrtc-server
> webpack-dev-server --mode development --https --cert ./certs/cert.pem --key ./certs/key.pem --hot --inline --progress --colors --watch --compress --content-base ./dist  --port 8086 --host 0.0.0.0

Start WS Server: bind => ws://0.0.0.0:4442
Start WSS Server: bind => wss://0.0.0.0:4443
 10% building modules 1/1 modules 0 activeℹ ｢wds｣: Project is running at https://0.0.0.0:8086/
ℹ ｢wds｣: webpack output is served from /
ℹ ｢wds｣: Content not from webpack is served from /Users/Sites/webrtc/flutter-webrtc-server/dist
✖ ｢wdm｣: Hash: 20c9379ed53a3fe1c1ae
Version: webpack 4.17.1
Time: 3838ms
Built at: 22/08/2018 18:02:05
 1 asset
Entrypoint main = main.20c9379e.bundle.js
[./node_modules/loglevel/lib/loglevel.js] 7.68 KiB {main} [built]
[./node_modules/react-dom/index.js] 1.33 KiB {main} [built]
[./node_modules/react/index.js] 190 bytes {main} [built]
[./node_modules/strip-ansi/index.js] 161 bytes {main} [built]
[./node_modules/url/url.js] 22.8 KiB {main} [built]
[./node_modules/webpack-dev-server/client/index.js?https://0.0.0.0:8086] (webpack)-dev-server/client?https://0.0.0.0:8086 7.78 KiB {main} [built]
[./node_modules/webpack-dev-server/client/overlay.js] (webpack)-dev-server/client/overlay.js 3.58 KiB {main} [built]
[./node_modules/webpack/hot sync ^\.\/log$] (webpack)/hot sync nonrecursive ^\.\/log$ 170 bytes {main} [built]
[0] multi (webpack)-dev-server/client?https://0.0.0.0:8086 (webpack)/hot/dev-server.js ./src/index.js 52 bytes {main} [built]
[./node_modules/webpack/hot/dev-server.js] (webpack)/hot/dev-server.js 1.61 KiB {main} [built]
[./node_modules/webpack/hot/emitter.js] (webpack)/hot/emitter.js 75 bytes {main} [built]
[./node_modules/webpack/hot/log-apply-result.js] (webpack)/hot/log-apply-result.js 1.27 KiB {main} [built]
[./node_modules/webpack/hot/log.js] (webpack)/hot/log.js 1.11 KiB {main} [built]
[./src/App.js] 13.1 KiB {main} [built]
[./src/index.js] 466 bytes {main} [built]
    + 328 hidden modules

ERROR in ./node_modules/@material-ui/icons/Menu.js
Module not found: Error: Can't resolve '@babel/runtime/helpers/builtin/interopRequireDefault' in '/Users/Sites/webrtc/flutter-webrtc-server/node_modules/@material-ui/icons'
 @ ./node_modules/@material-ui/icons/Menu.js 3:29-92
 @ ./src/App.js
 @ ./src/index.js
 @ multi (webpack)-dev-server/client?https://0.0.0.0:8086 (webpack)/hot/dev-server.js ./src/index.js

ERROR in ./node_modules/@material-ui/icons/Videocam.js
Module not found: Error: Can't resolve '@babel/runtime/helpers/builtin/interopRequireDefault' in '/Users/Sites/webrtc/flutter-webrtc-server/node_modules/@material-ui/icons'
 @ ./node_modules/@material-ui/icons/Videocam.js 3:29-92
 @ ./src/App.js
 @ ./src/index.js
 @ multi (webpack)-dev-server/client?https://0.0.0.0:8086 (webpack)/hot/dev-server.js ./src/index.js

ERROR in ./node_modules/@material-ui/icons/Call.js
Module not found: Error: Can't resolve '@babel/runtime/helpers/builtin/interopRequireDefault' in '/Users/Sites/webrtc/flutter-webrtc-server/node_modules/@material-ui/icons'
 @ ./node_modules/@material-ui/icons/Call.js 3:29-92
 @ ./src/App.js
 @ ./src/index.js
 @ multi (webpack)-dev-server/client?https://0.0.0.0:8086 (webpack)/hot/dev-server.js ./src/index.js

ERROR in ./node_modules/@material-ui/icons/CallEnd.js
Module not found: Error: Can't resolve '@babel/runtime/helpers/builtin/interopRequireDefault' in '/Users/Sites/webrtc/flutter-webrtc-server/node_modules/@material-ui/icons'
 @ ./node_modules/@material-ui/icons/CallEnd.js 3:29-92
 @ ./src/App.js
 @ ./src/index.js
 @ multi (webpack)-dev-server/client?https://0.0.0.0:8086 (webpack)/hot/dev-server.js ./src/index.js

ERROR in ./node_modules/@material-ui/icons/VideocamOff.js
Module not found: Error: Can't resolve '@babel/runtime/helpers/builtin/interopRequireDefault' in '/Users/Sites/webrtc/flutter-webrtc-server/node_modules/@material-ui/icons'
 @ ./node_modules/@material-ui/icons/VideocamOff.js 3:29-92
 @ ./src/App.js
 @ ./src/index.js
 @ multi (webpack)-dev-server/client?https://0.0.0.0:8086 (webpack)/hot/dev-server.js ./src/index.js

ERROR in ./node_modules/@material-ui/icons/Mic.js
Module not found: Error: Can't resolve '@babel/runtime/helpers/builtin/interopRequireDefault' in '/Users/Sites/webrtc/flutter-webrtc-server/node_modules/@material-ui/icons'
 @ ./node_modules/@material-ui/icons/Mic.js 3:29-92
 @ ./src/App.js
 @ ./src/index.js
 @ multi (webpack)-dev-server/client?https://0.0.0.0:8086 (webpack)/hot/dev-server.js ./src/index.js

ERROR in ./node_modules/@material-ui/icons/MicOff.js
Module not found: Error: Can't resolve '@babel/runtime/helpers/builtin/interopRequireDefault' in '/Users/Sites/webrtc/flutter-webrtc-server/node_modules/@material-ui/icons'
 @ ./node_modules/@material-ui/icons/MicOff.js 3:29-92
 @ ./src/App.js
 @ ./src/index.js
 @ multi (webpack)-dev-server/client?https://0.0.0.0:8086 (webpack)/hot/dev-server.js ./src/index.js

ERROR in ./node_modules/@material-ui/icons/utils/createSvgIcon.js
Module not found: Error: Can't resolve '@babel/runtime/helpers/builtin/interopRequireDefault' in '/Users/Sites/webrtc/flutter-webrtc-server/node_modules/@material-ui/icons/utils'
 @ ./node_modules/@material-ui/icons/utils/createSvgIcon.js 3:29-92
 @ ./node_modules/@material-ui/icons/Menu.js
 @ ./src/App.js
 @ ./src/index.js
 @ multi (webpack)-dev-server/client?https://0.0.0.0:8086 (webpack)/hot/dev-server.js ./src/index.js
Child html-webpack-plugin for "index.html":
     1 asset
    Entrypoint undefined = ./index.html
    [./node_modules/html-webpack-plugin/lib/loader.js!./src/index.html] 370 bytes {0} [built]
    [./node_modules/lodash/lodash.js] 527 KiB {0} [built]
    [./node_modules/webpack/buildin/global.js] (webpack)/buildin/global.js 489 bytes {0} [built]
    [./node_modules/webpack/buildin/module.js] (webpack)/buildin/module.js 497 bytes {0} [built]
ℹ ｢wdm｣: Failed to compile.

You can try  npm i babel-runtime,  May lack an npm dependency.

That solved it, although I had to delete node_modules and package-lock file, install babel-runtime, then install as per usual.

authors: ROTGP cloudwebrtc

repo: cloudwebrtc/flutter-webrtc-server


text:
For rendering, any features to do header.tmpl / footer. tmpl etc?

i realised ctx.HTML is much slower than ctx.String... possible to speed this up? 50k req/s vs 15k req/s
For rendering, any features to do header.tmpl / footer. tmpl etc?
for header and footer so to have consistency. just curious how to stack them together. now i'm doing a lot of repeats. how to stack them together?
                ctx.HTML(consts.StatusOK, "index.tmpl", utils.H{
                        "t": "Main website",
                        "h": "Head website",
                        "b": "Body website",
                })

@hiqsociety  Can you use front and back-end separation design?

authors: FGYFFFF hiqsociety

repo: cloudwego/hertz-examples


text:
how to use different tlsCfg like fasthttp in example code?

i have a problem with the tls configuration.
sometimes depending on the ip address, i will use 1 version of tlsCfg, or another version of tlsCfg. I can do this switch in fasthttp when running in reverse proxy mode easily. how do i do the same for the below?
basically i'm using different tls cert for different types of ip origin... and sometimes domain name if i need to
fasthttp
for {
	conn, err := ln.Accept()
	if err != nil {
		panic(err) // TODO: handle error.
	}

	ip, _, err := net.SplitHostPort(conn.RemoteAddr().String())
	if err != nil {
		log.Printf("could not parse remote addr: %s\n", err)
		conn.Close()
		continue
	}

	var tlsCfg *tls.Config
                      if ip == "1.1.1.1" {
                         tlsCfg = //something{}
                      }else if ip == "123.123.123.123" {
                         tlsCfg = //something{}
                      }
	tlsConn := tls.Server(conn, tlsCfg)

	gopool.Go(func() {
		if err := server.ServeConn(tlsConn); err != nil {
			log.Printf("e1x = %s", err)
		}
	})
}

hertz?
	tlsCfg := &tls.Config{

		GetCertificate: func(hello *tls.ClientHelloInfo) (*tls.Certificate, error) {
			ip, _, err := net.SplitHostPort(hello.Conn.RemoteAddr().String())
			if err != nil {
				return nil, err
			}
                        if ip == "1.1.1.1" {
				return &cert, nil
			}else if ip == "123.123.123.123" {
				return &cert, nil
			}
	        })
	}

	//**??? oh no doesn't work same way as fasthttp**
	h := server.New(server.WithHostPorts(":443"), server.WithALPN(true), server.WithTLS(tlsCfg), server.WithListenConfig(&cfg))

	h.Use(func(cc context.Context, ctx *app.RequestContext) {
		ProxyHandlerHertz(cc, ctx)
	})

	h.Spin()

refer to https://www.cloudwego.io/docs/hertz/tutorials/basic-feature/protocol/tls/
https://github.com/cloudwego/hertz-examples/

Note：Currently, Hertz TLS server is not supported Netpoll network library temporarily.
h := server.Default(server.WithTLS(cfg), server.WithTransport(netpoll.NewTransporter)) support is still on the way.

is it already updated for tls or is there a workaround? sry i read but cant find

authors: li-jin-gou ultperf

repo: cloudwego/hertz


text:
docs(README): update documentation description and link

What type of PR is this?
docs
Check the PR title.

[X] This PR title match the format: <type>(optional scope): <description>
[X] The description of this PR title is user-oriented and clear enough for others to understand.

(Optional) Translate the PR title into Chinese.
更新 readme 中文档相关的描述和超链接
(Optional) More detail description for this PR(en: English/zh: Chinese).

en:
zh(optional):
Which issue(s) this PR fixes:

Long-term stale status, the context is no longer clear, close it first, and resubmit the pr if necessary.

authors: GuangmingLuo welkeyever


text:
Kitex Streaming (GRPC) 模式下，destService 让人费解

Is your feature request related to a problem? Please describe.
以 https://github.com/cloudwego/kitex-examples/tree/main/streaming 作为 DEMO 模板，在 istio 中启用 mTLS，会导致无法连接，经排查
client, err := echo.NewClient("demo", client.WithHostPorts("demo-server:8888"))

NewClient 中的第一个参数 destService 会被填充至 Authority，而在 istio virtualhost 匹配规则中，只包含了服务名  demo-server 而无 demo 导致无法正确的解析匹配，参考 GRPC 的实现
https://github.com/grpc/grpc-go/blob/master/clientconn.go#L1693
建议将 destService 作为可选参数在 GRPC 模式下。

谢谢反馈，请问如果destservice用“demo-server”是否还有问题？

@yanickxia 确认下service name保持一致是否还有问题

authors: YangruiEmma yanickxia

repo: cloudwego/kitex


text:
Custom model

I found Layoutlmv2 takes both the image and the context into the pretrain. Why would you use BERT and not Layoutlmv2. I want custom to use layoutlmv2 for encoder, is it possible? Thank you so much

Hi @MinhQuang2021
You may customize this part
https://github.com/clovaai/spade/blob/a85574ceaa00f1878a23754f283aa66bc2daf082/spade/model/model.py#L743-L775
The backbone is based on hugginface transformers thus it shouldn't be difficult to adapt layoutlm.
During the major development , layoutlm wasn't available. Also layoutlm is not pre-trained for Japanese and Indonesian. Thus we initialized the spade encoder with the subset of BERT weights (note that spade encoder ≠ BERT).
Best

Thank you, I really want to apply it on my custom dataset for my language. But creating a dataset with a label like CORD is quite time consuming, so I want to ask you, How many datasets will give good results? Is the standard dataset for this model important? Is this model applicable to unseen data well?
Can you give me some knowledge in EL task I still find it quite confusing in paper to just generate graph and decode it.
I am learning it for my graduation project. Thank you very much

I noticed when set self.hparam.token_lv_boxing == True. parse is parsed differently. Why in Cord_test.yml and Cord_train.yml you both set it to True. Can you explain how it works for me?

why do you set token_lv_boxing= True in CORD , and in FUNSD you set token_lv_boxing=False .
How does token_lv_boxing work? I noticed it changes the parse result when training.

hello, can you help me find the code to apply inferring_method?
- tca_rel_s
- tca_rel_g

Hi @MinhQuang2021
I would say, roughly 1,000 documents are required for the reasonable performance.
Under zero-shot setting, the domain should be similar for reasonable performance. Otherwise, you'll observe a large performance drop.
About the EL task, FUNSD consists of four types of fields: "Header" "Question", "Answer", "ETC".
The EL task aims to connect "Header" → "Question", "Question" → "Answer".
So it is kind of "grouping two fields where each field consist of multiple serialized words".
When token_lv_boxing=True, spade draws directed arrows between tokens. For the noisy OCR data like receipt, this makes a better result. For FUNSD, the task assumes a perfect OCR so I turned it off.
The data augmentation option is automatically turned off during prediction. Sorry for the confusion.
Sorry for being late in reply. Good luck with your project!

repo: clovaai/spade


text:
fargate-scheduler: Your AWS account is currently blocked and thus cannot launch any Fargate pods

Describe the bug
I followed this example and I am stuck with the following status:
Events:
  Type     Reason            Age    From               Message
  ----     ------            ----   ----               -------
  Warning  FailedScheduling  2m59s  fargate-scheduler  Your AWS account is currently blocked and thus cannot launch any Fargate pods

To Reproduce
Steps to reproduce the behavior:

Navigate to the serverless tutorial
Run it
See error

Code
terraform {
  required_version = "~> 1.2.4"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.21.0"
    }
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "~>2.12.0"
    }
    helm = {
      source  = "hashicorp/helm"
      version = ">= 2.5" # "~>2.6.0"
    }
    null = {
      source  = "hashicorp/null"
      version = ">= 3.0" # "~>3.1.0"
    }
  }
}

provider "aws" {
  profile = "syncifyEKS-terraform-admin"
  region  = local.region

  default_tags {
    tags = {
      Environment = "Staging"
      Owner       = "BT-Compliance"
      Terraform   = "True"
    }
  }
}

#
# Housekeeping
#

locals {
  project_name    = "syncify-dev"
  cluster_name    = "${local.project_name}-eks-cluster"
  cluster_version = "1.22"
  region          = "us-west-1"
}

/*
The following 2 data resources are used get around the fact that we have to wait
for the EKS cluster to be initialised before we can attempt to authenticate.
*/

data "aws_eks_cluster" "default" {
  name = module.eks.cluster_id
}

data "aws_eks_cluster_auth" "default" {
  name = module.eks.cluster_id
}

provider "kubernetes" {
  host                   = data.aws_eks_cluster.default.endpoint
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.default.certificate_authority[0].data)
  token                  = data.aws_eks_cluster_auth.default.token
}

provider "helm" {
  kubernetes {
    host                   = data.aws_eks_cluster.default.endpoint
    cluster_ca_certificate = base64decode(data.aws_eks_cluster.default.certificate_authority[0].data)
    token                  = data.aws_eks_cluster_auth.default.token
  }
}
#############################################################################################
#############################################################################################

# Create EKS Cluster
#############################################################################################
#############################################################################################
# Create VPC for EKS Cluster
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "3.14.2"

  name = local.cluster_name
  cidr = "10.0.0.0/16"

  azs             = ["${local.region}a", "${local.region}b", "${local.region}c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24"]     #, "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24"] #, "10.0.103.0/24"]

  enable_nat_gateway     = true
  single_nat_gateway     = true
  one_nat_gateway_per_az = false

  manage_default_network_acl    = true
  default_network_acl_tags      = { Name = "${local.cluster_name}-default" }
  manage_default_route_table    = true
  default_route_table_tags      = { Name = "${local.cluster_name}-default" }
  manage_default_security_group = true
  default_security_group_tags   = { Name = "${local.cluster_name}-default" }

  public_subnet_tags = {
    "kubernetes.io/cluster/${local.cluster_name}" = "shared"
    "kubernetes.io/role/elb"                      = 1
  }

  private_subnet_tags = {
    "kubernetes.io/cluster/${local.cluster_name}" = "shared"
    "kubernetes.io/role/internal-elb"             = 1
  }
}

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "18.26.3"

  cluster_name    = local.cluster_name
  cluster_version = local.cluster_version

  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnets

  cluster_addons = {
    kube-proxy = {
      addon_version     = data.aws_eks_addon_version.this["kube-proxy"].version
      resolve_conflicts = "OVERWRITE"
    }
    vpc-cni = {
      addon_version     = data.aws_eks_addon_version.this["vpc-cni"].version
      resolve_conflicts = "OVERWRITE"
    }
  }

  # manage_aws_auth_configmap = true

  fargate_profiles = {
    default = {
      name = "default"
      selectors = [
        { namespace = "default" }
      ]
    }

    kube_system = {
      name = "kube-system"
      selectors = [
        { namespace = "kube-system" }
      ]
    }
  }
}

data "aws_eks_addon_version" "this" {
  for_each = toset(["coredns", "kube-proxy", "vpc-cni"])

  addon_name         = each.value
  kubernetes_version = module.eks.cluster_version
  most_recent        = true
}

################################################################################
# Modify EKS CoreDNS Deployment
################################################################################

data "aws_eks_cluster_auth" "this" {
  name = module.eks.cluster_id
}

locals {
  kubeconfig = yamlencode({
    apiVersion      = "v1"
    kind            = "Config"
    current-context = "terraform"
    clusters = [{
      name = module.eks.cluster_id
      cluster = {
        certificate-authority-data = module.eks.cluster_certificate_authority_data
        server                     = module.eks.cluster_endpoint
      }
    }]
    contexts = [{
      name = "terraform"
      context = {
        cluster = module.eks.cluster_id
        user    = "terraform"
      }
    }]
    users = [{
      name = "terraform"
      user = {
        token = data.aws_eks_cluster_auth.this.token
      }
    }]
  })
}

# Separate resource so that this is only ever executed once
resource "null_resource" "remove_default_coredns_deployment" {
  triggers = {}

  provisioner "local-exec" {
    interpreter = ["/bin/bash", "-c"]
    environment = {
      KUBECONFIG = base64encode(local.kubeconfig)
    }

    # We are removing the deployment provided by the EKS service and replacing it through the self-managed CoreDNS Helm addon
    # However, we are maintaing the existing kube-dns service and annotating it for Helm to assume control
    command = <<-EOT
      kubectl --namespace kube-system delete deployment coredns --kubeconfig <(echo $KUBECONFIG | base64 --decode)
    EOT
  }
}

resource "null_resource" "modify_kube_dns" {
  triggers = {}

  provisioner "local-exec" {
    interpreter = ["/bin/bash", "-c"]
    environment = {
      KUBECONFIG = base64encode(local.kubeconfig)
    }

    # We are maintaing the existing kube-dns service and annotating it for Helm to assume control
    command = <<-EOT
      echo "Setting implicit dependency on ${module.eks.fargate_profiles["kube_system"].fargate_profile_pod_execution_role_arn}"
      kubectl --namespace kube-system annotate --overwrite service kube-dns meta.helm.sh/release-name=coredns --kubeconfig <(echo $KUBECONFIG | base64 --decode)
      kubectl --namespace kube-system annotate --overwrite service kube-dns meta.helm.sh/release-namespace=kube-system --kubeconfig <(echo $KUBECONFIG | base64 --decode)
      kubectl --namespace kube-system label --overwrite service kube-dns app.kubernetes.io/managed-by=Helm --kubeconfig <(echo $KUBECONFIG | base64 --decode)
    EOT
  }

  depends_on = [
    null_resource.remove_default_coredns_deployment
  ]
}

################################################################################
# CoreDNS Helm Chart (self-managed)
################################################################################

resource "helm_release" "coredns" {
  name             = "coredns"
  namespace        = "kube-system"
  create_namespace = false
  description      = "CoreDNS is a DNS server that chains plugins and provides Kubernetes DNS Services"
  chart            = "coredns"
  version          = "1.19.4"
  repository       = "https://coredns.github.io/helm"
  force_update     = true
  recreate_pods    = true

  # For EKS image repositories https://docs.aws.amazon.com/eks/latest/userguide/add-ons-images.html
  values = [
    <<-EOT
      image:
        repository: 602401143452.dkr.ecr.us-west-1.amazonaws.com/eks/coredns
        tag: ${data.aws_eks_addon_version.this["coredns"].version}
      deployment:
        name: coredns
        annotations:
          eks.amazonaws.com/compute-type: fargate
      service:
        name: kube-dns
        annotations:
          eks.amazonaws.com/compute-type: fargate
      podAnnotations:
        eks.amazonaws.com/compute-type: fargate
      EOT
  ]
  depends_on = [
    null_resource.modify_kube_dns
  ]
}

Expected behavior
coredns pods should have gotten scheduled.
Any help would be greatly appreciated.

hi @arnav13081994 - this appears to be an issue with your account and is not related to the code provided here. Please reach out to your AWS support to resolve

repo: clowdhaus/eks-reference-architecture


text:
No Response when Querying MDNS Cast Devices

Hello,
I'm trying to implement your MDNS library in a project I have that aims to communicate with chromecast devices.
I'm trying to get results for the record _googlecast._tcp.local, but keep getiting a TimeoutException:
  Thu, 18 May 2017 14:37:32 -0500 [ DEBUG ] api.php::testReact - Function fired!
  Thu, 18 May 2017 14:37:37 -0500 [ ERROR ] api.php::{closure} - Error:
  React\Dns\Query\TimeoutException: DNS query for _googlecast._tcp.local timed out in
  /volume1/Webroot/Phlex/vendor/clue/mdns-react/src/MulticastExecutor.php:84
  Stack trace:
  #0 [internal function]: Clue\React\Mdns\MulticastExecutor->Clue\React\Mdns\{closure}
  (Object(React\EventLoop\Timer\Timer))
  #1 /volume1/Webroot/Phlex/vendor/react/event-loop/src/Timer/Timers.php(90):
  call_user_func(Object(Closure), Object(React\EventLoop\Timer\Timer))
  #2 /volume1/Webroot/Phlex/vendor/react/event-loop/src/StreamSelectLoop.php(177):
  React\EventLoop\Timer\Timers->tick()
  #3 /volume1/Webroot/Phlex/api.php(1857): React\EventLoop\StreamSelectLoop->run()
  #4 /volume1/Webroot/Phlex/api.php(1732): testReact()
  #5 /volume1/Webroot/Phlex/api.php(164): scanDevices()
  #6 {main}

I don't see any other glaring errors in my logs that would indicate a systemic error, but I could also be mistaken.
I'm invoking the lookup like so:
  function testReact() {
   write_log("Function fired!");
      $name = '_googlecast._tcp.local';
      $loop = React\EventLoop\Factory::create();
      $factory = new Clue\React\Mdns\Factory($loop);
      $mdns = $factory->createResolver();
      $mdns->resolve($name)->then(function ($value) {
          write_log("Value: ".$value);
      },function ($value) {
          write_log("Error: ".$value,"ERROR");
      });
      $loop->run();
  }

I'm running this on Synology with apache 2.4 and php7.
Thanks!

Thanks for your interesting question!
It looks like what you're trying to achieve is actually DNS-SD instead of mDNS, as mentioned in the readme:

This library implements the mDNS protocol as defined in RFC 6762. Note that this protocol is related to, but independent of, DNS-Based Service Discovery (DNS-SD) as defined in RFC 6763.

In other words: mDNS deals with finding the IP of a given hostname via multicast, while DNS-SD can be used to find a list of devices that offer a certain service.
I hope this helps :+1:

repo: clue/php-mdns-react


text:
clusternet schduler support SchdulerExtender to extend?

clusternet schduler support SchdulerExtender to extend?

clusternet schduler support SchdulerExtender to extend?

No. And I don't suggest using extender to extend scheduler.
Clusternet scheduler is using scheduling framework, which uses plugins to implement different scheduling phases. And it is easy to hook your out-of-tree plugins.

If want to update the logic code of score plugin , have a way to hot update the plugin but no restart clusternet schduler？

No. For scheduling framework, you need to rebuild scheduler and update it.
Scheduler extender is also not suggested by Kubernetes community.

If want to update the logic code of score plugin , have a way to hot update the plugin but no restart clusternet schduler？

No. For scheduling framework, you need to rebuild scheduler and update it.
Scheduler extender is also not suggested by Kubernetes community.

OK. Thanks a lot.

repo: clusternet/clusternet


text:
comment out checking cluster type on registration

What type of PR is this?
kind/bug
What this PR does / why we need it:
Currently there is only one kind of ClusterType, i.e., EdgeCluster. Commenting out checking cluster type to allow more customized cluster type.
Which issue(s) this PR fixes:

Fixes #89
Special notes for your reviewer:

/lgtm

authors: dixudx huxiaoliang


text:
Empty catch blocks trigger indentation errors for version > 1.11.1

An empty catch block (with or without comments) causes coffeelint to complain about inconsistent indentation.
Sample code
try
  console.log 'a tisket'
  console.log 'a tasket'
catch err
  # We'll eat the exception

console.log 'All done'

coffeelint@1.11.1 finds no errors with this code. However, later version (1.12.0, 1.12.1) both give the following error
$ coffeelint sample.coffee
  ✗ sample.coffee
     ✗ #4: Line contains inconsistent indentation. Expected 2 got 0.

✗ Lint! » 1 error and 0 warnings in 1 file

Thanks for the fix Shuan Wang :) :+1:

no prob. I just release v1.13.0 with all the fixes.

Please update the changelog too.

authors: AsaAyers akshat1 swang

repo: clutchski/coffeelint


text:
remove legacy runtime

because:

seeing pretty decent adoption (edit: of kube-runtime) across github code search
haven't gotten complaints about new runtime
no need to keep this entirely unmaintained module around to confuse people

some counter-points. There is still matt butcher's blog-post that made it to hackernews which uses it, but that's hopefully passed now?
I have updated all my old blog posts (and even written a new one).
Can hold off until we have written something official about kube-runtime potentially.
What do people think?

i'll trust the thumbs up consensus :-)

repo: clux/kube-rs


text:
Google Maps Language localization

Display the map in pt-BR

thanks!

authors: cmdalbem gutobenn

repo: cmdalbem/bikedeboa


text:
Invalid Schnorr Siganture - Example: Basic spend using key-path

I have a method to send sats from one p2tr address to another one. I followed this example to implement it.
The validation goes through, but when I submit the transaction to mempool.space (or blockstream, same thing), I get the following response:
sendrawtransaction RPC error: {"code":-26,"message":"non-mandatory-script-verify-flag (Invalid Schnorr signature)"}
Here is the code I send sats with (essentially the same as the example, but with many UTXOs in tx input):
https://pastebin.com/hBGXNnJe

Here is the decoded TX that fails to be broadcast:
{
  version: 2,
  vin: [
    {
      txid: 'fd13e6e779960e0ba56405928524d1077575568a58b8e123275f11cb8630a816',
      vout: 0,
      scriptSig: [],
      sequence: 'fffffffd',
      witness: [Array]
    }
  ],
  vout: [
    {
      value: 1000n,
      scriptPubKey: '5120b32ce90751de8b076dc9c8f6d46f967abe6cc7a4e97c452ff17444bb60c5890b'
    }
  ],
  locktime: 0
}

I think the problem may be here with txInput.vout:
Signer.taproot.sign(taprootPk, txData, txInput.vout)

The index value should be the index of the input being signed, so like this:
for (let i = 0; i < txData.vin.length; i++) {
      txData.vin[i].witness = [
        Signer.taproot.sign(taprootPk, txData, i),
      ];
    }

Try that change and let me know if it works.
p.s the n notes a BigInt type. They are a relatively new type in javascript.

@cmdruid thanks, fixed this one! But the error is still there, unfortunately :( something else is also wrong

Where are you getting the keys from?
You may want to try skipping this part:
const [taprootPk] = Tap.getSecKey(pk);
const [taprootPub] = Tap.getPubKey(pub);

This step adds an empty tweak to each key in your key-pair, which obfuscates the keys for privacy.
However it is not necessary and not all wallets bother to do this step, so you may want to try omitting it and signing with the keys you have directly.

@cmdruid I tried skipping tweaking, but no luck, same error.
I generate the keys myself, then tweak them, then give the taproot address to the user.
Then somewhere in the future the user funds the taproot address and I do this sending method (I invoke it with not tweaked private key and the method tweaks the key inside it, so that it has access to the taproot address the user has funded).
Also, so that you don't have to waste time, while trying to guess what's wrong, I created this minimal example with all the method inputs, how I generate the keys etc., before I invoke the method:
https://pastebin.com/qH73NDqC#google_vignette

Do you end up getting the same tweaked key-pair in both cases? Does the tweaked public key, when encoded as an address, match the address of the utxo being spent?

@cmdruid Yes, the same tweaked key-pair in both cases 😢
UTXO address matches as well, yes, I re-verify UTXO data for the address being spent doing this request:
GET https://blockstream.info/testnet/api/address/tb1pxez9u8zkzhgephpus2a3fuz7jujhpeujml32a5d4g57aj9wjdqrqh02yen/utxo

What does Signer.taproot.verify(txData, i) not check during verification? I know UTXOs could be one thing, but those are correct, what else could it miss?
Maybe it will be easier for me to debug, if I at least know what could be wrong.

@cmdruid I also can reproduce this error in keyspend.test.ts.
I just removed the wallet stuff, as I don't have a local node.
Then I put my private key there, my UTXO input data/output data and set the network to 'testnet'.
Then, after running the test (it runs successfully), I took the TX hex and posted it to the blockstream node like this:
curl --request POST
--url https://blockstream.info/testnet/api/tx
--header 'Content-Type: text/plain'
--header 'User-Agent: insomnia/9.3.2'
--data 020000000001010449081422de6fda2d995662ab51909a3a45bf422bcf47b40af047c94d467b360000000000fdffffff015203000000000000160014d0829aa329e5716e71b10cb17a6a33df8caf72a3014095df63eff8710b308c2f69b693cf7db731cd320c0789d5fad412a1911d1105e243efbd39d2d74cfd3dd0b9fe6b8e1e5387b92b61364c4d664b609441b984d2a000000000

The pubkey that I am decoding from the address "tb1pxez9u8zkzhgephpus2a3fuz7jujhpeujml32a5d4g57aj9wjdqrqh02yen" is the following:
36445e1c5615d190dc3c82bb14f05e972570e792dfe2aed1b5453dd915d26806
Are you signing with a private key that matches this public key?

@cmdruid
Secret: c8ec44f2fd52560af4aaab3210c104d18cf5904c75288d182124c2905da69102
You can import into Unisat Testnet to see for yourself. Address is derived from public and you'll see the correct address there.
Just try this test and see for yourself:
https://pastebin.com/raw/vhn2YJvt
You'll see all the correct keys in the test, the UTXO used here is also correct. And the test will pass, of course.
But then, use the TX Hex and submit it to blockstream (or mempool.space). The BTC node will reject it.
Submission request:
curl --request POST
--url https://blockstream.info/testnet/api/tx
--header 'Content-Type: text/plain'
--data

@cmdruid okay, I realized my error, incorrect value was inputted into prevout.
Sorry for disturbing :)

no problem. I'm glad that you were able to get it working!

authors: cmdruid maxgmer

repo: cmdruid/tapscript


text:
Agregando Bootstrap al sitio web

¿Qué tarea hace la rama a agregar?
Incorpora Bootstrap, usa un slider para agregar dinamismo, mejora la estética.
¿Cómo ver la función que realiza?
sitio001/index.
Es en el:

[x] Frontend.
[ ] Backend.

Desea agregar alguna descripción adicional?
Agregar JQuery antes que bootstrap.

Bootstrap revisado y aprovado.


text:
Update Book “2024-02-08/index-2”

Automatically generated by Netlify CMS

👷 Deploy Preview for comforting-lamington-e443cb processing.

Name
Link

🔨 Latest commit
0d3bd5e61b6efdc246e3e522851ec730fd7c2ec3

🔍 Latest deploy log
https://app.netlify.com/sites/comforting-lamington-e443cb/deploys/65c58461b2b6b900097b87c0

repo: cmpasc/VueDN