> On Sept. 12, 2014, 7:15 p.m., John Speidel wrote: > > Please don't merge this. > > The blueprint processing code shouldn't be dealing with repo url's. > > > > Instead, what should be done is to change the code that writes out the xml > > file during installation. > > There are 3 relevant fields in the xml: > > "base_url" : value to be used unless overridden by an explicit call > > "default_base_url" : value specified in the stack xml > > "latest_base_url" : latest obtained from an external URL query. May be null > > > > When writing this file, base_url should be set to the value of > > latest_base_url if it is not null. This is only done once when Ambari is > > installed so it will remain consistent after a cluster is created. This > > way, the latest will be used by default when deploying via a blueprint and > > the repo url will not change even if the latest value does. A user can > > still explicitly set a value for the repo url which will override base_url > > if desired. > > > > Please see continuing conversation in Jira. > > Cabir Zounaidou wrote: > John, i wont' merge until you say Ship It. I liked the idea of writing > the latest url (from repoinfo.xml) in an xml during Ambari installation. > But what i don't understand is that the deploying cluster via a blueprint, > still needs to use this xml file (created using installation time) and update > the repo resources using repo api's, is that okay or am i missing something > here? Also, we need to have some processing code on the repo url still, if > the scenario is that before deploying the cluster via BP, user has updated > the stack repository url using the rest api.
Cabir, what I am suggesting is that there will be no repo related logic in the blueprint code. The BP processing code will not pass a any repo information during install operations. All logic for determining the proper repo url is in the agent code. This code already exists and handles the case where the user explicitly sets the repo url via the api. The only change will be that for cases where we can obtain a "latest" repo, this will be set in the configuration during installation (once) as the value that is used by default instead of the value from the stack xml. So, the existing agent code will work as is with this change since all we are doing is changing how we initialize the value that the agent was already using. The code for handling the explicit setting of the repo url already exists and will remain unchanged. When a user sets the repo url explicitly prior to an install, the code that provides that repo url to the agent will work with our change as all we are doing is changing how we set the default value. Please ping me if you still have questions and we can talk. - John ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/25572/#review53203 ----------------------------------------------------------- On Sept. 12, 2014, 7:08 p.m., Cabir Zounaidou wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/25572/ > ----------------------------------------------------------- > > (Updated Sept. 12, 2014, 7:08 p.m.) > > > Review request for Ambari, Erik Bergenholtz, John Speidel, Mahadev Konar, and > Robert Nettleton. > > > Bugs: AMBARI-7286 > https://issues.apache.org/jira/browse/AMBARI-7286 > > > Repository: ambari > > > Description > ------- > > Steps: > 1. Create a blueprint > {"configurations": [], "host_groups": [ > {"name": "host1", > "cardinality": "1", > "components": [ > {"name": "DATANODE" }, > {"name": "SECONDARY_NAMENODE" }, > {"name": "NAMENODE" }, > {"name": "ZOOKEEPER_SERVER" }, > {"name": "ZOOKEEPER_CLIENT" }, > {"name": "HDFS_CLIENT" } > ] > } > ], "Blueprints": { > "blueprint_name": "hdfszk", > "stack_name": "HDP", > "stack_version": "2.1" > }} > > 2. Create a cluster template to deploy using blueprint > { > "configurations": [ > { > > "cluster-env":{ > "tag":"version1", > "properties":{"security_enabled":"false","kerberos_domain": > "EXAMPLE.COM","ignore_groupsusers_create": "false", "smokeuser": "ambari-qa", > "user_group": "hadoop"} > } > } > > ], > "blueprint": "hdfszk", > "host_groups": [ > { > "name": "host1", > "hosts": [ > { "fqdn": "c6401.ambari.apache.org" } > ] > } > ] > } > > 3. Deploy an instance of cluster using the above cluster template > > 4. Verify the URL's in the Admin/repositories page of UI. It was not be > using the latest url specified in the repoinfo.xml of the given stack and > version before this fix. > > > Diffs > ----- > > > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/ClusterResourceProvider.java > f40979c > > ambari-server/src/test/java/org/apache/ambari/server/controller/internal/ClusterResourceProviderTest.java > d5f575a > > Diff: https://reviews.apache.org/r/25572/diff/ > > > Testing > ------- > > 1. Ran the unit tests. The ClusterResourceProviderTest.java has unit for > deploying cluster using blueprint. > 2. Manually tested deploying a cluster from the UI > 3. Ran the REST-API's to test deploying cluster using blueprint and verified > the repository urls. > 3.1 Create a blueprint using the API > curl -i --user > admin:adminhttp://c6401.ambari.apache.org:8080/api/v1/blueprints/blueprint1 > -X POST -d @/tmp/myblueprint_template_json -H "X-Requested-By: ambari" > 3.2 Create a cluster from the template which was using the blueprint > curl -i --user admin:admin -H "X-Requested-By: ambari" -X POST -d > @/tmp/cluster_blueprint_instance.json > http://c6401.ambari.apache.org:8080/api/v1/clusters/cl1 > 3.3 Checked the status of the task until it is completed. > 3.4 Verified in the UI that Admin/repositories page shows up the latest > repo url (specified in repoinfo.xml) for the stack selected. > > > Thanks, > > Cabir Zounaidou > >
