Skip to content
This repository has been archived by the owner before Nov 9, 2022. It is now read-only.

Add AMI set entity and its create and delete endpoints #85

Merged
merged 4 commits into from Jul 4, 2016

Conversation

anarute
Copy link
Contributor

@anarute anarute commented Jun 6, 2016

I was not sure about its endpoints, if I am using the correct AMI Set properties.


properties: {

amiSetId: base.Entity.types.String,
Copy link
Contributor

@jhford jhford Jun 6, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since we're in the AmiSet class, let's call this just 'id'

@jhford
Copy link
Contributor

jhford commented Jun 6, 2016

@anarute really good first pass! Most of the things that are needed are here. It seems like you and @djmitche are talking about json-schema for the AmiSets, which is a great idea. Otherwise, looking great!

@djmitche
Copy link
Contributor

djmitche commented Jun 6, 2016

OK that was a lot of comments, but this looks good!

If I remember correctly, you were able to run the tests for the provisioner. Do they still run after your changes?

You will also need some tests in test-src/manage_ami_set_test.js, similar to test-src/manageworkertype_test.js (but again, much shorter, since so far AMI sets are a lot less complicated than worker types). If it would help you out, I can write up a test for one of the API methods as an example.

@anarute
Copy link
Contributor Author

anarute commented Jun 7, 2016

Thank you @djmitche and @jhford for the comments and feedback! It was really helpful to understand things better. I think (if I have not added more things to fix) that I've covered most part of the issues, could you please review it again?

title: 'Create new AMI Set',
stability: base.API.stability.stable,
description: [
'Create an AMI Set. An AMI Set is a collection of AMIs with a single name.',
].join('\n'),
}, async function (req, res) {
let input = req.body;
let amiSet = req.params.amiSetId;
let AmiSetId = req.params.id;
Copy link
Contributor

@jhford jhford Jun 7, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AmiSet is a 'class', but this isn't referring to the class. This is referring to a string and so should be amiSetId or just id... either one is fine.

@anarute anarute force-pushed the add-ami-sets branch 5 times, most recently from 9fa0787 to 906fcd6 Compare Jun 28, 2016
try {
await base.Entity.scan.call(this, {}, {
handler: function(item) {
amiSetList.push(item.json());
Copy link
Contributor

@jhford jhford Jun 28, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is a listing method, we should be pushing the item.id property instead of the complete item in a json-serializable format. If the goal is a load-all method, let's call it loadAll() to match the worker type here

Copy link
Contributor

@djmitche djmitche Jun 28, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe we already had some discussion of this in the PR? Many of the list methods in TC services return the entire object, e.g., auth.listClients. The reason not to do so is if it requires additional queries or a lot more bandwidth. Neither is the case here. We have the additional information about each AMI set returned from Azure, so why not provide it to the user?

@anarute
Copy link
Contributor Author

anarute commented Jun 28, 2016

@jhford I fixed the things you've mentioned:

@djmitche
Copy link
Contributor

djmitche commented Jun 28, 2016

If we need loadAll(), it's easy enough to add in a new PR :)

@jhford
Copy link
Contributor

jhford commented Jun 29, 2016

So there's a problem here. The create ami set endpoint has a json-schema that forces there to be an ID parameter in the request body. The problem is that we already have that specified in the parameters of the api method. The create schema should only have the amis object.

@jhford
Copy link
Contributor

jhford commented Jun 29, 2016

Ok. So I think the only issue left here is removing the createAmiSet json-schema allowing an ID value. The only place we should be supplying the id value is the parameter that we bake into the /ami-set/:id route.

I think with that change, i'm 99% sure that we're ready to merge!

@anarute
Copy link
Contributor Author

anarute commented Jun 30, 2016

@jhford I removed the id property from createAmiSet schema, could you review the code again, please?

- region
- hvm
- pv
lastModified:
Copy link
Contributor

@jhford jhford Jul 1, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry that I didn't see this before, but we also should not have last modified as an allowed field in the request. we will generate this value inside the api handler, so forcing a value here that we won't end up using isn't ideal.

@jhford jhford merged commit 72a05c9 into taskcluster:master Jul 4, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants