Skip to Main Content
Forums

Cloud Platform

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Using curl to pull back instance and orchestration states

DabbsyNov 14 2017 — edited Dec 15 2017

I’m running some curl from a shell script to get the state of an instance and also an orchestration.

In the below, I’ve replaced my actual tenant and info with the oracle sample code and I’ve previously generated a cookie and passed this into the $COMPUTE_COOKIE parameter.

This cookie works fine.

When I try and run curl against the instance it returns all the information I want – but how can I just pull back the state? 

curl -X GET \

  -H "Cookie: $COMPUTE_COOKIE"   \

  -H "Accept: application/oracle-compute-v3+json" \

https://api-z999.compute.us0.oraclecloud.com/instance/Compute-acme/jack.jones@example.com/dev1/f653a677-b566-4f92-8e93-71d47b364119z999.compute.us0.oraclecloud.com/instance/Compute-acme/jack.jones@example.com/dev1/f653a677-b566-4f92-8e93-71d47b364119

The curl command pulls back dozens of fields including "state": "running" (which is the only piece of information I need) – but there’s that much date in there in one long string, so it’s difficult to easily pull out the state only – can I just ask for the state to be returned?  or how can I easily extract the state only.

when I run a similar command to the get the state of the orchestration:-

curl -X GET \

  -H "Cookie: $COMPUTE_COOKIE"   \

  -H "Accept: application/oracle-compute-v3+json" \

https://api-z999.compute.us0.oraclecloud.com/orchestrations/Compute-acme/jack.jones@example.com/dev1/

this returns

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

<html><head>

<title>403 Forbidden</title>

</head><body>

<h1>Forbidden</h1>

<p>You don't have permission to access /orchestrations/Compute-acme/jack.jones@example.com/dev1/ on this server.</p>

</body></html>

If I’ve created the orchestration and the instance myself (and I can access the instance - first command in the post) how can I not have the permissions to see the orchestration?  Is there a way of checking these permissions at the instance and the orchestration level or is there something else going on that might be stopping me?

Any assistance appreciated - this is my first venture with cloud, curl and the REST APIs.

thanks a lot

Jonathan

Comments

807588
Does the client program send a packet and then expect a reply? Because the reply won't always happen. UDP is a lossy protocol; it will drop packets, deliver packets out of order, and deliver multiple copies of packets. Your client sends a request and the network loses the packet; then your client will forever wait for the reply.

If you need reliable delivery use TCP instead.
807588
Hi,

Thanks for the fast reply. My client indeed waits for the reply. Let me desribe the entire story. On the first my client/server application was RMI based. I was thinking that since the server and the clients share the same LAN (and the LAN should be reliable), I could spare the overread of the RMI protocol and move to UDP, but the reality fits well with your explanation :-)

Before I go back to RMI, is there a way to configure timeouts on the client side, to it won't wait forever in such cases?

Thanks a lot,

Barak.
EJP
DatagramSocket.setSoTimeout()
JoachimSauer
BarakY wrote:
[...] I could spare the overread of the RMI protocol and move to UDP, but the reality fits well with your explanation :-)
You know, there are several levels of abstraction between RMI and UDP. You could move to a custom TCP-based protocol for example. There you'd still have the reliability, but could interact on a lower level and have more control.
807588
Sounds yammi :-)

Can you guide me where can I find some pointers/refs of these issues?
Do you suggest considering low-level socket programming?
Do you think such programming will result with better performance?

Barak.
EJP
Can you guide me where can I find some pointers/refs of these issues?
The Javadoc.
Do you suggest considering low-level socket programming?
Isn't that exactly what he said?
Do you think such programming will result with better performance?
Compared to what?
807588
Compared to what?
To Sun RMI implementation.
JoachimSauer
BarakY wrote:
Compared to what?
To Sun RMI implementation.
Possibly, not necessarily. What it does give you is more control, but also more work. You can easily control what gets sent when and therefore have the chance to improve performance.
1 - 8
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Jan 12 2018
Added on Nov 14 2017
#java-cloud-service
2 comments
478 views