@bgrant0607 PTAL

@erictune what is PTAL?

PTAL = "please take a look" or "please take another look".

As per docs/api-conventions.md "the convention is to use a list of
subobjects containing name fields"

#2004

It sounds like status is buggy

On Tue, Jan 20, 2015 at 8:43 AM, Eric Tune notifications@github.com wrote:

PTAL = "please take a look" or "please take another look".

Reply to this email directly or view it on GitHub
#3622 (comment)
.

but what about the other issue - missing info on ports/resources?

/cc @dchen1107

Yes, status should not be a map.

@abonas What info would you like to see about ports?

We plan to introduce a separate API for resource information. See the section about usage here:
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/resources.md

/cc @rjnagal

@bgrant0607 when I query for pod information and its containers, it's important to see what's going on with them in runtime. so if spec was ports XYZ, cpu A and memory B, I would like to see if indeed it matches the spec or is different. were the ports allocated? same ports? different ports?
otherwise, having only the spec information, there's nothing user can do to monitor/manage the runtime.

also, having an additional api means it's requiring more requests to server, more merging work and resolving relationships on client side. not very convenient for clients.

I will open a separate issue on the ports missing info, and keep this one for the buggy status structure

@dchen1107 are you working on it?

not at this moment, feel free grabbing it.

@bgrant0607
I'm trying to change PodInfo to be a list.

Should it only be changed in api v3 or also in v1 and v2? In general do we still want to modify api v1 and v2 or are those versions final?

How about internal representation of PodInfo? Do we want to keep it as it is or change to be compatible with external type? There is some internal code (pkg/kubelet/dockertools/docker.go) which relies on that PodInfo is a map. Do we want to try use externally and internally the same types when possible?

For consistency in beta3, I still endorse this. Brian is contemplating the
longer term of maps vs lists, and this may yet reverse. I don't see that
happening in v1.

I would make this change only in b3 and internal. If keeping it as a map
is important internally, we CAN do that, but it requires a conversion func,
which I know Brian is trying to avoid.

On Thu, Feb 26, 2015 at 4:57 AM, Piotr Szczesniak notifications@github.com
wrote:

@bgrant0607 https://github.com/bgrant0607
I'm trying to change PodInfo to be a list.

Should it only be changed in api v3 or also in v1 and v2? In general do we
still want to modify api v1 and v2 or are those versions final?

How about internal representation of PodInfo? Do we want to keep it as it
is or change to be compatible with external type? There is some internal
code (pkg/kubelet/dockertools/docker.go) which relies on that PodInfo is a
map. Do we want to try use externally and internally the same types when
possible?

Reply to this email directly or view it on GitHub
#3622 (comment)
.

I recommend waiting on this until at least Monday.

Thanks for the info.

@bgrant0607 ping me when you're ready.

Sorry for the delay. Hold off on this a bit longer. Debate is ongoing. I recommend choosing something else to work on in the short term.

No problem. Sure, I'm working also on other issues. Please let me know the decision will be made.

Ok, decision is lists: #4889.

Sorry for the delay.

Thanks for the info.

I did not get the sense that a decision had been made and I've been
watching that thread...

On Tue, Mar 10, 2015 at 11:01 AM, Brian Grant notifications@github.com
wrote:

Ok, decision is lists: #4889
#4889.

Sorry for the delay.

—
Reply to this email directly or view it on GitHub
#3622 (comment)
.

I don't think that this makes the v1.0 cut.

We were trying to get this into v1beta3, since it currently violates our stated API convention.

That said, I'm fine with demoting the priority at this point, esp. since it's in status rather than spec.

I'm about to finish this change (still need to fix one test)