Re: [openstack-dev] [TripleO] Set WIP for stale patches?
On 18/09/14 00:29, James Polley wrote: > > > On Wed, Sep 17, 2014 at 6:26 PM, mar...@redhat.com > <mailto:mar...@redhat.com> <mailto:mandr...@redhat.com>> wrote: > > Hi, > > as part of general housekeeping on our reviews, it was discussed at last > week's meeting [1] that we should set workflow -1 for stale reviews > (like gerrit used to do when I were a lad). > > The specific criteria discussed was 'items that have a -1 from a core > but no response from author for 14 days'. This topic came up again > during today's meeting and it wasn't clear if the intention was for > cores to start enforcing this? So: > > Do we start setting WIP/workflow -1 for those reviews that have a -1 > from a core but no response from author for 14 days > > > I'm in favour of doing this; as long as we make it clear that we're > doing it to help us focus review effort on things that are under active > development - it doesn't mean we think the patch shouldn't land, it just > means we know it's not ready yet so we don't want reviewers to be > looking at it until it moves forward. > > For the sake of making sure new developers don't get put off, I'd like > to see us leaving a comment explaining why we're WIPing the change and > noting that uploading a new revision will remove the WIP automatically > +1 - indeed, I'd say as part of this discussion, or if/when it comes up as a motion for a vote in the weekly meeting, we should also put out and agree on the 'standard' text to be used for this and stick it on the wiki (regardless of whether this is to be implemented manually at first and perhaps automated later), thanks, marios "setting workflow -1 as this review has been inactive for two weeks following a negative review. Please see the wiki @ foo for more information. Note that once you upload a new revision the workflow is expected to be reset (feel free to shout on freenode/#tripleo if it isn't)." > > thanks, marios > > [1] > > http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-09-09-19.04.log.html > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Set WIP for stale patches?
On 17/09/14 16:40, Charles Crouch wrote: > > > - Original Message - >> Hi, >> >> as part of general housekeeping on our reviews, it was discussed at last >> week's meeting [1] that we should set workflow -1 for stale reviews >> (like gerrit used to do when I were a lad). >> >> The specific criteria discussed was 'items that have a -1 from a core >> but no response from author for 14 days'. This topic came up again >> during today's meeting and it wasn't clear if the intention was for >> cores to start enforcing this? So: >> >> Do we start setting WIP/workflow -1 for those reviews that have a -1 >> from a core but no response from author for 14 days >> >> thanks, marios >> >> [1] >> http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-09-09-19.04.log.html > > So it looks like this has already started.. > > https://review.openstack.org/#/c/105275/ > > I think we need to document on the wiki *precisely* the criteria for setting > WIP/workflow -1. For example that review above has a Jenkins failure but no > core reviews at all. +1 on being precise - another case in point: https://review.openstack.org/#/c/102304/ this review has a *-2* from core, which seems to 'stick' for future revisions; the last revision is from > 14 days ago, so does this fulfill the criteria (I'd say it doesn't)? Not sure if you were also suggesting that -1 from Jenkins also counts, which imo makes sense... 'items that have a -1 from core or jenkins, or a -2 from core on the latest revision, and no response from author for 14 days' Really this needs to be put as a motion and voted on in the next meeting, thanks, marios > >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] Release Report
1. os-apply-config: release: 0.1.21 --> 0.1.22 --> https://pypi.python.org/pypi/os-apply-config/0.1.22 --> http://tarballs.openstack.org/os-apply-config/os-apply-config-0.1.22.tar.gz 2. os-refresh-config: no changes, 0.1.7 3. os-collect-config: no changes, 0.1.28 4. os-cloud-config: release: 0.1.9 --> 0.1.10 --> https://pypi.python.org/pypi/os-cloud-config/0.1.10 --> http://tarballs.openstack.org/os-cloud-config/os-cloud-config-0.1.10.tar.gz 5. diskimage-builder: release: 0.1.30 --> 0.1.31 --> https://pypi.python.org/pypi/diskimage-builder/0.1.31 --> http://tarballs.openstack.org/diskimage-builder/diskimage-builder-0.1.31.tar.gz 6. dib-utils: no changes, 0.0.6 7. tripleo-heat-templates: release: 0.7.6 --> 0.7.7 --> https://pypi.python.org/pypi/tripleo-heat-templates/0.7.7 --> http://tarballs.openstack.org/tripleo-heat-templates/tripleo-heat-templates-0.7.7.tar.gz 8: tripleo-image-elements: release: 0.8.6 --> 0.8.7 --> https://pypi.python.org/pypi/tripleo-image-elements/0.8.7 --> http://tarballs.openstack.org/tripleo-image-elements/tripleo-image-elements-0.8.7.tar.gz 9: tuskar: release 0.4.11 --> 0.4.12 --> https://pypi.python.org/pypi/tuskar/0.4.12 --> http://tarballs.openstack.org/tuskar/tuskar-0.4.12.tar.gz 10. python-tuskarclient:release 0.1.11 --> 0.1.12 --> https://pypi.python.org/pypi/python-tuskarclient/0.1.12 --> http://tarballs.openstack.org/python-tuskarclient/python-tuskarclient-0.1.12.tar.gz ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] Set WIP for stale patches?
Hi, as part of general housekeeping on our reviews, it was discussed at last week's meeting [1] that we should set workflow -1 for stale reviews (like gerrit used to do when I were a lad). The specific criteria discussed was 'items that have a -1 from a core but no response from author for 14 days'. This topic came up again during today's meeting and it wasn't clear if the intention was for cores to start enforcing this? So: Do we start setting WIP/workflow -1 for those reviews that have a -1 from a core but no response from author for 14 days thanks, marios [1] http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-09-09-19.04.log.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Propose adding StevenK to core reviewers
On 09/09/14 21:32, Gregory Haynes wrote: > Hello everyone! > > I have been working on a meta-review of StevenK's reviews and I would > like to propose him as a new member of our core team. > > As I'm sure many have noticed, he has been above our stats requirements > for several months now. More importantly, he has been reviewing a wide > breadth of topics and seems to have a strong understanding of our code > base. He also seems to be doing a great job at providing valuable > feedback and being attentive to responses on his reviews. > > As such, I think he would make a great addition to our core team. Can > the other core team members please reply with your votes if you agree or > disagree. > +1 > Thanks! > Greg > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Tripleo] Release Report
1. os-apply-config: release: 0.1.19 --> 0.1.20 --> https://pypi.python.org/pypi/os-apply-config/0.1.20 --> http://tarballs.openstack.org/os-apply-config/os-apply-config-0.1.20.tar.gz 2. os-refresh-config: no changes, 0.1.7 3. os-collect-config: release: 0.1.27 --> 0.1.28 --> https://pypi.python.org/pypi/os-collect-config/0.1.28 --> http://tarballs.openstack.org/os-collect-config/os-collect-config-0.1.28.tar.gz 4. os-cloud-config: release: 0.1.7 --> 0.1.8 --> https://pypi.python.org/pypi/os-cloud-config/0.1.8 --> http://tarballs.openstack.org/os-cloud-config/os-cloud-config-0.1.8.tar.gz 5. diskimage-builder: release: 0.1.28 --> 0.1.29 --> https://pypi.python.org/pypi/diskimage-builder/0.1.29 --> http://tarballs.openstack.org/diskimage-builder/diskimage-builder-0.1.29.tar.gz 6. dib-utils: release: 0.0.5 --> 0.0.6 --> https://pypi.python.org/pypi/dib-utils/0.0.6 --> http://tarballs.openstack.org/dib-utils/dib-utils-0.0.6.tar.gz 7. tripleo-heat-templates: release: 0.7.4 --> 0.7.5 --> https://pypi.python.org/pypi/tripleo-heat-templates/0.7.5 --> http://tarballs.openstack.org/tripleo-heat-templates/tripleo-heat-templates-0.7.5.tar.gz 8. tripleo-image-elements: release: 0.8.4 --> 0.8.5 --> https://pypi.python.org/pypi/tripleo-image-elements/0.8.5 --> http://tarballs.openstack.org/tripleo-image-elements/tripleo-image-elements-0.8.5.tar.gz 9. tuskar: release 0.4.9 --> 0.4.10 --> https://pypi.python.org/pypi/tuskar/0.4.10 --> http://tarballs.openstack.org/tuskar/tuskar-0.4.10.tar.gz 10. python-tuskarclient:release 0.1.9 --> 0.1.10 --> https://pypi.python.org/pypi/python-tuskarclient/0.1.10 --> http://tarballs.openstack.org/python-tuskarclient/python-tuskarclient-0.1.10.tar.gz ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Tripleo] Release report
1. os-apply-config: no changes, 0.1.19 2. os-refresh-config: no changes, 0.1.7 3. os-collect-config: no changes, 0.1.27 4. os-cloud-config: release: 0.1.6 --> 0.1.7 --> https://pypi.python.org/pypi/os-cloud-config/0.1.7 --> http://tarballs.openstack.org/os-cloud-config/os-cloud-config-0.1.7.tar.gz 5. diskimage-builder: release: 0.1.27 --> 0.1.28 --> https://pypi.python.org/pypi/diskimage-builder/0.1.28 --> http://tarballs.openstack.org/diskimage-builder/diskimage-builder-0.1.28.tar.gz 6. dib-utils: release: 0.0.4 --> 0.0.5 --> https://pypi.python.org/pypi/dib-utils/0.0.5 --> http://tarballs.openstack.org/dib-utils/dib-utils-0.0.5.tar.gz 7. tripleo-heat-templates: release: 0.7.3 --> 0.7.4 --> https://pypi.python.org/pypi/tripleo-heat-templates/0.7.4 --> http://tarballs.openstack.org/tripleo-heat-templates/tripleo-heat-templates-0.7.4.tar.gz 8: tripleo-image-elements: release: 0.8.3 --> 0.8.4 --> https://pypi.python.org/pypi/tripleo-image-elements/0.8.4 --> http://tarballs.openstack.org/tripleo-image-elements/tripleo-image-elements-0.8.4.tar.gz 9: tuskar: release 0.4.8 --> 0.4.9 --> https://pypi.python.org/pypi/tuskar/0.4.9 --> http://tarballs.openstack.org/tuskar/tuskar-0.4.9.tar.gz 10. python-tuskarclient:release 0.1.8 --> 0.1.9 --> https://pypi.python.org/pypi/python-tuskarclient/0.1.9 --> http://tarballs.openstack.org/python-tuskarclient/python-tuskarclient-0.1.9.tar.gz ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Rotating the weekly Neutron meeting
On 13/08/14 17:05, Kyle Mestery wrote: > Per this week's Neutron meeting [1], it was decided that offering a > rotating meeting slot for the weekly Neutron meeting would be a good > thing. This will allow for a much easier time for people in > Asia/Pacific timezones, as well as for people in Europe. > > So, I'd like to propose we rotate the weekly as follows: > > Monday 2100UTC > Tuesday 1400UTC HUGE +1 and thanks! > > If people are ok with these time slots, I'll set this up and we'll > likely start with this new schedule in September, after the FPF. > > Thanks! > Kyle > > [1] > http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-08-11-21.00.html > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Tripleo] Release report
This was my first run so if I missed something please ping me, esp if you are in need of a stable branch (for those projects we do that for), 1. os-apply-config: no changes, 0.1.19 2. os-refresh-config: no changes, 0.1.7 3. os-collect-config: no changes, 0.1.25 4. os-cloud-config: release: 0.1.4 --> 0.1.5 --> https://pypi.python.org/pypi/os-cloud-config/0.1.5 --> http://tarballs.openstack.org/os-cloud-config/os-cloud-config-0.1.5.tar.gz 5. diskimage-builder: no_changes, 0.1.26 6. dib-utils: no_changes, 0.0.4 7. tripleo-heat-templates: release: 0.7.1 --> 0.7.2 --> https://pypi.python.org/pypi/tripleo-heat-templates/0.7.2 --> http://tarballs.openstack.org/tripleo-heat-templates/tripleo-heat-templates-0.7.2.tar.gz 8: tripleo-image-elements: release: 0.8.1 --> 0.8.2 --> https://pypi.python.org/pypi/tripleo-image-elements/0.8.2 --> http://tarballs.openstack.org/tripleo-image-elements/tripleo-image-elements-0.8.2.tar.gz 9: tuskar: release 0.4.6 --> 0.4.7 --> https://pypi.python.org/pypi/tuskar/0.4.7 --> http://tarballs.openstack.org/tuskar/tuskar-0.4.7.tar.gz 10. python-tuskarclient:no_changes, 0.1.8 I'll deal with the process_bugs thing before end of week, thanks! marios ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat][TripleO] Heat can't retrieve stack list
On 05/08/14 08:43, Peeyush Gupta wrote: > Hi all, > > I have been trying to set up tripleo using instack. > When I try to deploy overcloud, I get a heat related > error. Here it is: > > [stack@localhost ~]$ heat stack-list > ERROR: Timeout while waiting on RPC response - topic: "engine", RPC method: > "list_stacks" info: "" > > Now, heat-engine is running: > > > [stack@localhost ~]$ ps ax | grep heat-engine > 15765 pts/0S+ 0:00 grep --color=auto heat-engine > 25671 ?Ss 0:27 /usr/bin/python /usr/bin/heat-engine --logfile > /var/log/heat/engine.log > > Here is the heat-engine log: > > 2014-08-04 07:57:26.321 25671 ERROR heat.engine.resource [-] CREATE : Server > "SwiftStorage0" [b78e4c74-f446-4941-8402-56cf46401013] Stack "overcloud" > [9bdc71f5-ce31-4a9c-8d72-3adda0a2c66e] > 2014-08-04 07:57:26.321 25671 TRACE heat.engine.resource Traceback (most > recent call last): > 2014-08-04 07:57:26.321 25671 TRACE heat.engine.resource File > "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 420, in > _do_action > 2014-08-04 07:57:26.321 25671 TRACE heat.engine.resource while not > check(handle_data): > 2014-08-04 07:57:26.321 25671 TRACE heat.engine.resource File > "/usr/lib/python2.7/site-packages/heat/engine/resources/server.py", line 545, > in check_create_complete > 2014-08-04 07:57:26.321 25671 TRACE heat.engine.resource return > self._check_active(server) > 2014-08-04 07:57:26.321 25671 TRACE heat.engine.resource File > "/usr/lib/python2.7/site-packages/heat/engine/resources/server.py", line 561, > in _check_active > 2014-08-04 07:57:26.321 25671 TRACE heat.engine.resource raise exc > 2014-08-04 07:57:26.321 25671 TRACE heat.engine.resource Error: Creation of > server overcloud-SwiftStorage0-fnl43ebtcsom failed. > 2014-08-04 07:57:26.321 25671 TRACE heat.engine.resource > 2014-08-04 07:57:27.152 25671 WARNING heat.common.keystoneclient [-] > stack_user_domain ID not set in heat.conf falling back to using default > 2014-08-04 07:57:27.494 25671 WARNING heat.common.keystoneclient [-] > stack_user_domain ID not set in heat.conf falling back to using default > 2014-08-04 07:57:27.998 25671 WARNING heat.common.keystoneclient [-] > stack_user_domain ID not set in heat.conf falling back to using default > 2014-08-04 07:57:28.312 25671 WARNING heat.common.keystoneclient [-] > stack_user_domain ID not set in heat.conf falling back to using default > 2014-08-04 07:57:28.799 25671 WARNING heat.common.keystoneclient [-] > stack_user_domain ID not set in heat.conf falling back to using default > 2014-08-04 07:57:29.452 25671 WARNING heat.common.keystoneclient [-] > stack_user_domain ID not set in heat.conf falling back to using default > 2014-08-04 07:57:30.106 25671 WARNING heat.common.keystoneclient [-] > stack_user_domain ID not set in heat.conf falling back to using default > 2014-08-04 07:57:30.516 25671 WARNING heat.common.keystoneclient [-] > stack_user_domain ID not set in heat.conf falling back to using default > 2014-08-04 07:57:31.499 25671 WARNING heat.engine.service [-] Stack create > failed, status FAILED > > Any idea how to figure this error out? FYI I am seeing the same, it seems Heat didn't start properly after following the undercloud install. I'm going to go back and try again today in case I missed something, or hopefully find out more, marios > > Thanks, > Peeyush Gupta > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Status of A/A HA for neutron-metadata-agent?
On 03/08/14 13:07, Gary Kotton wrote: > Hi, > Happy you asked about this. This is an idea that we have: > > Below is a suggestion on how we can improve the metadata service. This can > be done by leveraging the a Load balancers supports X-Forwarded-For.The > following link has two diagrams. The first is the existing support (may be > a little rusty here, so please feel free to correct) and the second is the > proposal. > https://docs.google.com/drawings/d/19JCirhj2NVVFZ0Vbnsxhyxrm1jjzEAS3ZAMzfBR > C-0E/edit?usp=sharing > > Metadata proxy support: the proxy will receive the HTTP request. It will > then perform a query to the Neutron service (1) to retrieve the tenant id > and the instance id from the neutron service. A proxy request will be sent > to Nova for the metadata details (2). > > Proposed support: > > 1. There will be a load balancer vip 254.169.254.169 (this can be > reached either via the L3 agent of the DG on the DHCP. > 2. The LB will have a server farm of all of the Nova API's (this makes the > soon highly available) > 1. Replace the destination IP and port with the Nova metadata IP and > port > 2. Replace the source IP with the interface IP > 3. Insert the header X-Fowarded-For (this will have the original > source IP of the VM) > > > > 1. When the Nova metadata service receives the request, according to a > configuration variable > (https://github.com/openstack/nova/blob/master/nova/api/metadata/handler.py > #L134), will interface with the neutron service to get the instance_id and > the tenant id. This will be done by using a new extension. With the > details provided by Neutron Nova will provide the correct metadata for the > instance > 2. A new extension will be added to Neutron that will enable a port > lookup. The port lookup will have two input values and will return the > port which has the instance id and the tenant id. > 1. LB source IP this is the LB source IP that interfaces with the Nova > API. When we create the edge router for the virtual network we will have a > mapping of the edge LB ip <-> network id. This will enable us to get the > virtual network for the port > 2. Fixed port IP this with the virtual network will enable us to get the > specific port. > > Hopefully in the coming days a spec will be posted that will provide more > details > thanks for that info Gary, the diagram in particular forced me to go read a bit about the metadata agent (i was mostly just proxying for the original question). I obviously miss a lot of the details (will be easier once the spec is out) but it seems like you're proposing an addition (port-lookup) that will change the way the metadata agent is called; in fact does it make the neutron metadata proxy obsolete? I will keep a look out for the spec, thanks, marios > Thanks > Gary > > > > On 8/1/14, 6:11 PM, "mar...@redhat.com" wrote: > >> Hi all, >> >> I have been asked by a colleague about the status of A/A HA for >> neutron-* processes. From the 'HA guide' [1], l3-agent and >> metadata-agent are the only neutron components that can't be deployed in >> A/A HA (corosync/pacemaker for a/p is documented as available 'out of >> the box' for both). >> >> The l3-agent work is approved for J3 [4] but I am unaware of any work on >> the metadata-agent and can't see any mention in [2][3]. Is this someone >> has looked at, or is planning to (though ultimately K would be the >> earliest right?)? >> >> thanks! marios >> >> [1] http://docs.openstack.org/high-availability-guide/content/index.html >> [2] https://wiki.openstack.org/wiki/NeutronJunoProjectPlan >> [3] >> https://urldefense.proofpoint.com/v1/url?u=https://launchpad.net/neutron/% >> 2Bmilestone/juno-3&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6h >> goMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=TZXQIMHmAX22lC0YOyItiXOrAA%2FegHqY5cN >> I73%2B0jJ8%3D%0A&s=b81f4d5919b317628f56d0313143cee8fca6e47f639a59784eb19da >> 3d88681da >> [4] >> http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/l3-h >> igh-availability.rst >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Status of A/A HA for neutron-metadata-agent?
On 02/08/14 02:22, Assaf Muller wrote: > Hey Marios, comments inline. > > - Original Message - >> Hi all, >> >> I have been asked by a colleague about the status of A/A HA for >> neutron-* processes. From the 'HA guide' [1], l3-agent and >> metadata-agent are the only neutron components that can't be deployed in >> A/A HA (corosync/pacemaker for a/p is documented as available 'out of >> the box' for both). >> >> The l3-agent work is approved for J3 [4] but I am unaware of any work on >> the metadata-agent and can't see any mention in [2][3]. Is this someone >> has looked at, or is planning to (though ultimately K would be the >> earliest right?)? >> > > With L3 HA turned on you can run the metadata agent on all network nodes. > The active instance of each router will have the proxy up in its namespace > and it will forward it to the agent as expected. perfect thanks Assaf as well as for the follow up clarifications on irc, I didn't realise this was the case, all the best, marios > >> thanks! marios >> >> [1] http://docs.openstack.org/high-availability-guide/content/index.html >> [2] https://wiki.openstack.org/wiki/NeutronJunoProjectPlan >> [3] https://launchpad.net/neutron/+milestone/juno-3 >> [4] >> http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/l3-high-availability.rst >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] Status of A/A HA for neutron-metadata-agent?
Hi all, I have been asked by a colleague about the status of A/A HA for neutron-* processes. From the 'HA guide' [1], l3-agent and metadata-agent are the only neutron components that can't be deployed in A/A HA (corosync/pacemaker for a/p is documented as available 'out of the box' for both). The l3-agent work is approved for J3 [4] but I am unaware of any work on the metadata-agent and can't see any mention in [2][3]. Is this someone has looked at, or is planning to (though ultimately K would be the earliest right?)? thanks! marios [1] http://docs.openstack.org/high-availability-guide/content/index.html [2] https://wiki.openstack.org/wiki/NeutronJunoProjectPlan [3] https://launchpad.net/neutron/+milestone/juno-3 [4] http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/l3-high-availability.rst ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Proposal to add Jon Paul Sullivan and Alexis Lee to core review team
On 14/07/14 19:11, Ben Nemec wrote: > +1. In my experience they've both demonstrated that they know what > they're doing. > > I think the bikeshedding/grammar nits on specs is kind of a separate > issue that will need to be worked out in general. It's still very early > on in this new *-specs repo world, and I think everyone's still trying > to figure out where to draw the line on how much grammar/spelling > nit-picking is appropriate. +1 from me too for both. I agree with the gist of Tomas comments but I really agree with Ben's comments above ... trying to convey 'rules' about what constitutes bikeshedding is basically impossible given that there will be varying opinions. In any case, if it really is just e.g. a 'rephrase' or a small/inconsequential commit message nit/typo and as echoed by others here, you can just make a suggestion. A +1 (and not a -1 or even a +2 for example) should be sufficient to make that suggestion. Then its up to others to vote either way, and you haven't held up progress with a -1, just my 2c, thanks, marios > > -Ben > > On 07/09/2014 10:52 AM, Clint Byrum wrote: >> Hello! >> >> I've been looking at the statistics, and doing a bit of review of the >> reviewers, and I think we have an opportunity to expand the core reviewer >> team in TripleO. We absolutely need the help, and I think these two >> individuals are well positioned to do that. >> >> I would like to draw your attention to this page: >> >> http://russellbryant.net/openstack-stats/tripleo-reviewers-90.txt >> >> Specifically these two lines: >> >> +---+---++ >> | Reviewer | Reviews -2 -1 +1 +2 +A+/- % | Disagreements* >> | >> +---+---++ >> | jonpaul-sullivan | 1880 43 145 0 077.1% | 28 ( 14.9%) >> | >> | lxsli | 1860 23 163 0 087.6% | 27 ( 14.5%) >> | >> >> Note that they are right at the level we expect, 3 per work day. And >> I've looked through their reviews and code contributions: it is clear >> that they understand what we're trying to do in TripleO, and how it all >> works. I am a little dismayed at the slightly high disagreement rate, >> but looking through the disagreements, most of them were jp and lxsli >> being more demanding of submitters, so I am less dismayed. >> >> So, I propose that we add jonpaul-sullivan and lxsli to the TripleO core >> reviewer team. >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Time to break backwards compatibility for *cloud-password file location?
On 25/06/14 10:52, James Polley wrote: > Until https://review.openstack.org/#/c/83250/, the setup-*-password scripts > used to drop password files into $CWD, which meant that if you ran the > script from a different location next time, your old passwords wouldn't be > found. > > https://review.openstack.org/#/c/83250/ changed this so that the default > behaviour is to put the password files in $TRIPLEO_ROOT; but for backwards > compatibility we left the script checking to see if there's a file in the > current directory, and using that file in preference to $TRIPLEO_ROOT if it > exists. > > However, this behaviour is still confusing to people. I'm not entirely > clear on why it's confusing (it makes perfect sense to me...) but I imagine > it's because we still have the problem that the code works fine if run from > one directory, but run from a different directory it can't find passwords. > > There are two open patches which would break backwards compatibility and > only ever use the files in $TRIPLEO_ROOT: > > https://review.openstack.org/#/c/93981/ > https://review.openstack.org/#/c/97657/ > > The latter review is under more active development, and has suggestions > that the directory containing the password files should be parameterised, > defaulting to $TRIPLEO_ROOT. This would still break for anyone who relies > on the password files being in the directory they run the script from, but > at least there would be a fairly easy fix for them. > How about we: * parameterize as suggested by Fabio in the review @ https://review.openstack.org/#/c/97657/ * move setting of this param to more visible location (setup, like devtest_variables or testenv). We can then give this better visibility in the dev/test autodocs with a warning about the 'old' behaviour * add a deprecation warning to the code that reads from $CWD/tripleo-overcloud-passwords to say that this will now need to be set as a parameter in ... wherever. How long is a good period for this? I don't think we make much in terms of backwards compatibility guarantees right now do we? marios > To help decide if it's time to break backwards compatibility in this case > (and if so, how), I'd love to see some more comments on 97657. If we don't > want to break backwards compatibility, maybe comments about a better way to > handle the ambiguity would be helpful. > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][Flavors] Flavor framework implementation questions
On 29/05/14 00:48, Eugene Nikanorov wrote:
> Hi,
>
> I have two questions that previously were briefly discussed. Both of them
> still cause discussions within advanced services community, so I'd like to
> make final clarification in this email thread.
>
> 1. Usage of "Service Type Framework"
> I think right now there is a consensus that letting user to choose a vendor
> is not what neutron should do. To be more specific, having public
> 'provider' attribute on a resource may create certain problems
> for operators because it binds resource and implementation too tightly that
> it can't be maintained without changing user configuration.
> The question that was discussed is if it's ok to remove this public
> attribute and still use the rest of framework?
> I think the answer is yes: the binding between resource and implementing
> driver is ok if it's read-only and visible only to admin. This still serves
> as hint for dispatching requests to driver and also may help operator to
> troubleshoot issues.
> I'd like to hear other opinions on this because there are patches for vpn
> and fwaas that use STF with the difference described above.
pardon my ignorance, I don't know what STF is. I missed the summit
discussions ('provider attribute' on resources must have come up there).
My take on the 'specific vendor' issue is that there isn't one, given
the current proposal. From the discussion there I think there is a use
case for a user saying 'i want a firewall from foo_vendor' and as you
said it's just a specialised use-case of the flavor framework.
Furthermore, right now the 'capabilities' for Flavors are very loosely
defined (just key:value tags on Flavor resource). Why can't we just also
define a 'vendor:foo' capability and use it for that purpose. I imagine
I'm oversimplifying somewhere but would that not address the concerns?
marios
>
> 2. Choosing implementation and backend
> This topic was briefly touched at design session dedicated to flavors.
>
> Current proposal that was discussed on advanced services meetings was to
> employ 2-step scheduling as described in the following sample code:
> https://review.openstack.org/#/c/83055/7/neutron/tests/unit/test_flavors.pyline
> 38-56
>
> In my opinion the proposed way has the following benefits:
> - it delegates actual backend choosing to a driver.
> This way different vendors may not be required to agree on how to bind
> resource to a backend or any kind of other common implementation stuff that
> usually leads to lots of discussions.
> - allows different configurable vendor-specific algorithms to be used when
> binding resource to a backend
> - some drivers don't have notion of a backend because external entities
> manage backends for them
>
> Another proposal is to have single-step scheduling where each driver
> exposes the list of backends
> and then scheduling just chooses the backend based on capabilities in the
> flavor.
>
> I'd like to better understand the benefits of the second approach (this is
> all implementation so from user standpoint it doesn't make difference)
>
> So please add your opinions on those questions.
>
> My suggestion is also to have a short 30 min meeting sometime this or next
> week to finalize those questions. There are several patches and blueprints
> that depend on them.
>
> Thanks,
> Eugene.
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] BPs for Juno-1
On 28/05/14 17:57, Kyle Mestery wrote:
> On Wed, May 28, 2014 at 12:41 AM, mar...@redhat.com
> wrote:
>> On 27/05/14 17:14, Kyle Mestery wrote:
>>> Hi Neutron developers:
>>>
>>> I've spent some time cleaning up the BPs for Juno-1, and they are
>>> documented at the link below [1]. There are a large number of BPs
>>> currently under review right now in neutron-specs. If we land some of
>>> those specs this week, it's possible some of these could make it into
>>> Juno-1, pending review cycles and such. But I just wanted to highlight
>>> that I removed a large number of BPs from targeting Juno-1 now which
>>> did not have specifications linked to them nor specifications which
>>> were actively under review in neutron-specs.
>>>
>>> Also, a gentle reminder that the process for submitting specifications
>>> to Neutron is documented here [2].
>>>
>>> Thanks, and please reach out to me if you have any questions!
>>
>>
>> Hi Kyle,
>>
>> Can you please consider my "PUT /subnets/subnet allocation_pools:{}"
>> review at [1] for Juno-1? Also, I see you have included a bug [1] and
>> associated review [2] that I've worked on but the review is already
>> pushed to master. Is it there for any pending backports?
>>
> Done, I've added the bug referenced in [2] to Juno-1.
Thanks!
>
> With regards to [3] below, are you saying you would like to submit
> that as a backport to stable?
No I was more asking if that was the reason it was included (as it has
already been merged) - though I can do that if you think it's a good idea,
thanks, marios
>
>> thanks! marios
>>
>> [1] https://review.openstack.org/#/c/62042/
>> [2] https://bugs.launchpad.net/neutron/+bug/1255338
>> [3] https://review.openstack.org/#/c/59212/
>>
>>
>>>
>>> Kyle
>>>
>>> [1] https://launchpad.net/neutron/+milestone/juno-1
>>> [2] https://wiki.openstack.org/wiki/Blueprints#Neutron
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] BPs for Juno-1
On 27/05/14 17:14, Kyle Mestery wrote:
> Hi Neutron developers:
>
> I've spent some time cleaning up the BPs for Juno-1, and they are
> documented at the link below [1]. There are a large number of BPs
> currently under review right now in neutron-specs. If we land some of
> those specs this week, it's possible some of these could make it into
> Juno-1, pending review cycles and such. But I just wanted to highlight
> that I removed a large number of BPs from targeting Juno-1 now which
> did not have specifications linked to them nor specifications which
> were actively under review in neutron-specs.
>
> Also, a gentle reminder that the process for submitting specifications
> to Neutron is documented here [2].
>
> Thanks, and please reach out to me if you have any questions!
Hi Kyle,
Can you please consider my "PUT /subnets/subnet allocation_pools:{}"
review at [1] for Juno-1? Also, I see you have included a bug [1] and
associated review [2] that I've worked on but the review is already
pushed to master. Is it there for any pending backports?
thanks! marios
[1] https://review.openstack.org/#/c/62042/
[2] https://bugs.launchpad.net/neutron/+bug/1255338
[3] https://review.openstack.org/#/c/59212/
>
> Kyle
>
> [1] https://launchpad.net/neutron/+milestone/juno-1
> [2] https://wiki.openstack.org/wiki/Blueprints#Neutron
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] reservation of fixed ip
On 23/05/14 05:41, Mohammad Banikazemi wrote:
>
> Well, for a use case we had in mind we were trying to figure out how to
> simply get an IP address on a subnet. We essentially want to use such an
> address internally by the controller and make sure it is not used for a
> port that gets created on a network with that subnet. In this use case, an
> interface to IPAM for removing an address from the pool of available
> addresses (and the interface to possibly return the address to the pool)
> would be sufficient.
this and Carl's earlier response were my initial thought; this could
just be implemented through manipulation of allocation pools to make
sure the given address isn't handed out. Then the user can just manually
assign that address to the resource during creation/some existing update
mechanism (once pending reviews land and any others that were missed).
Slightly related in that it updates subnet allocation pools, I have a
review at [1] which adds PUT /subnets/subnet "allocation_pools: {}"
thanks! marios
[1] https://review.openstack.org/#/c/62042/
>
> Mohammad
>
>
>
> From: Carl Baldwin
> To: "OpenStack Development Mailing List (not for usage questions)"
> ,
> Date: 05/22/2014 06:19 PM
> Subject: Re: [openstack-dev] [Neutron] reservation of fixed ip
>
>
>
> If an IP is reserved for a tenant, should the tenant need to
> explicitly ask for that specific IP to be allocated when creating a
> floating ip or port? And it would pull from the regular pool if a
> specific IP is not requested. Or, does the allocator just pull from
> the tenant's reserved pool whenever it needs an IP on a subnet? If
> the latter, then I think Salvatore's concern still a valid one.
>
> I think if a tenant wants an IP address reserved then he probably has
> a specific purpose for that IP address in mind. That leads me to
> think that he should be required to pass the specific address when
> creating the associated object in order to make use of it. We can't
> do that yet with all types of allocations but there are reviews in
> progress [1][2].
>
> Carl
>
> [1] https://review.openstack.org/#/c/70286/
> [2] https://review.openstack.org/#/c/83664/
>
> On Thu, May 22, 2014 at 12:04 PM, Sławek Kapłoński
> wrote:
>> Hello
>>
>>
>> Dnia Wed, 21 May 2014 23:51:48 +0100
>> Salvatore Orlando napisał:
>>
>>> In principle there is nothing that should prevent us from
>>> implementing an IP reservation mechanism.
>>>
>>> As with anything, the first thing to check is literature or "related
>>> work"! If any other IaaS system is implementing such a mechanism, is
>>> it exposed through the API somehow?
>>> Also this feature is likely to be provided by IPAM systems. If yes,
>>> what constructs do they use?
>>> I do not have the answers to this questions, but I'll try to document
>>> myself; if you have them - please post them here.
>>>
>>> This new feature would probably be baked into neutron's IPAM logic.
>>> When allocating an IP, first check from within the IP reservation
>>> pool, and then if it's not found check from standard allocation pools
>>> (this has non negligible impact on availability ranges management, but
>>> these are implementation details).
>>> Aspects to consider, requirement-wise, are:
>>> 1) Should reservations also be classified by "qualification" of the
>>> port? For instance, is it important to specify that an IP should be
>>> used for the gateway port rather than for a floating IP port?
>>
>> IMHO it is not required when IP is reserved. User should have
>> possibility to reserve such IP for his tenant and later use it as he
>> want (floating ip, instance or whatever)
>>
>>> 2) Are reservations something that an admin could specify on a
>>> tenant-basis (hence an admin API extension), or an implicit mechanism
>>> that can be tuned using configuration variables (for instance create
>>> an IP reservation a for gateway port for a given tenant when a router
>>> gateway is set).
>>>
>>> I apologise if these questions are dumb. I'm just trying to frame this
>>> discussion into something which could then possibly lead to
>>> submitting a specification.
>>>
>>> Salvatore
>>>
>>>
>>> On 21 May 2014 21:37, Collins, Sean
>>> wrote:
>>>
(Edited the subject since a lot of people filter based on the
subject line)
I would also be interested in reserved IPs - since we do not deploy
the layer 3 agent and use the provider networking extension and a
hardware router.
On Wed, May 21, 2014 at 03:46:53PM EDT, Sławek Kapłoński wrote:
> Hello,
>
> Ok, I found that now there is probably no such feature to reserve
> fixed ip for tenant. So I was thinking about add such feature to
> neutron. I mean that it should have new table with reserved ips
> in neutron database and neutron will check this table every time
> when new port will be created (or updated) and IP should be
> associated with this port. If user has got reserved IP it shoul
Re: [openstack-dev] [Neutron] Introducing task oriented workflows
On 23/05/14 01:34, Salvatore Orlando wrote: > As most of you probably know already, this is one of the topics discussed > during the Juno summit [1]. > I would like to kick off the discussion in order to move towards a concrete > design. > > Preamble: Considering the meat that's already on the plate for Juno, I'm > not advocating that whatever comes out of this discussion should be put on > the Juno roadmap. However, preparation (or yak shaving) activities that > should be identified as pre-requisite might happen during the Juno time > frame assuming that they won't interfere with other critical or high > priority activities. > This is also a very long post; the TL;DR summary is that I would like to > explore task-oriented communication with the backend and how it should be > reflected in the API - gauging how the community feels about this, and > collecting feedback regarding design, constructs, and related > tools/techniques/technologies. fwiw, I was previously involved with the DMTF CIMI spec - the 'Job' resource defined there seems match the notion of 'task' as below [1]. The spec has a notion of nesting Jobs but any scheduling (as discussed in the etherpad you link below) was under discussion/tbd. > > At the summit a broad range of items were discussed during the session, and > most of them have been reported in the etherpad [1]. fwiw, there is mention in that etherpad about deferring a task/api call (so once you have a notion of 'Job' you can then schedule its execution). IMO this is an aside/added/unnecessary complication to what is potentially already a huge change. > > First, I think it would be good to clarify whether we're advocating a > task-based API, a workflow-oriented operation processing, or both. > > --> About a task-based API > > In a task-based API, most PUT/POST API operations would return tasks rather > than neutron resources, and users of the API will interact directly with > tasks. > I put an example in [2] to avoid cluttering this post with too much text. > As the API operation simply launches a task - the database state won't be > updated until the task is completed. (as an aside, in the example, another issue is what to return for GET /actual_resource whilst the task is still pending, you kind of cover that with the expanded status semantics discussed later): > > Needless to say, this would be a radical change to Neutron's API; it should > be carefully evaluated and not considered for the v2 API. > Even if it is easily recognisable that this approach has a few benefits, I > don't think this will improve usability of the API at all. Indeed this will > limit the ability of operating on a resource will a task is in execution on > it, and will also require neutron API users to change the paradigm the use > to interact with the API; for not mentioning the fact that it would look > weird if neutron is the only API endpoint in Openstack operating in this > way. +1 - I don't like this; a client will always get back a 'task' with a reference to the actual resource being acted upon. The client would then need to make a further API call to retrieve the (e.g.) created resource. BUT, how can we enable a task API without this model? Could we use an extension header to communicate the task URI? So API would remain unchanged, returning all the usual status but with the task URI included where necessary > For the Neutron API, I think that its operations should still be > manipulating the database state, and possibly return immediately after that > (*) - a task, or to better say a workflow will then be started, executed > asynchronously, and update the resource status on completion. you mean e.g. for create, client gets back 200 OK with the created resource inline, OR 202 Accepted for async tasks (so in the latter case resource state will be 'pending' until its completed, like server create in nova for example?). > > --> On workflow-oriented operations please excuse my ignorance, but I am not entirely sure what the distinction between 'task' and 'workflow' is (I wasn't at summit/discussion if that is some excuse). Is a workflow a directed graph of tasks? > > The benefits of it when it comes to easily controlling operations and > ensuring consistency in case of failures are obvious. For what is worth, I > have been experimenting introducing this kind of capability in the NSX > plugin in the past few months. I've been using celery as a task queue, and > writing the task management code from scratch - only to realize that the > same features I was implementing are already supported by taskflow. > > I think that all parts of Neutron API can greatly benefit from introducing > a flow-based approach. > Some examples: > - pre/post commit operations in the ML2 plugin can be orchestrated a lot > better as a workflow, articulating operations on the various drivers in a > graph > - operation spanning multiple plugins (eg: add router interface) could be > simplified using clearly defined t
Re: [openstack-dev] [Neutron][FYI] Bookmarklet for neutron gerrit review
On 09/05/14 12:33, mar...@redhat.com wrote:
> On 08/05/14 21:29, Henry Gessau wrote:
>> Have any of you javascript gurus respun this for the new gerrit version?
>> Or can this now be done on the backend somehow?
>
> haha, have been thinking this since the gerrit upgrade a couple days
> ago. It was very useful for reviews... I am NOT a javascript guru but
> since it's Friday I gave myself 15 minutes to play with it - this works
> for me:
>
>
> javascript:(function(){
> list = document.querySelectorAll('table.commentPanelHeader');
> for(i in list) {
> title = list[i];
> if(! title.innerHTML) { continue; }
> text = title.nextSibling;
> if (text.innerHTML.search('Build failed') > 0) {
> title.style.color='red'
> } else if(title.innerHTML.search('Jenkins|CI|Ryu|Testing|Mine')
>> = 0) {
just noticed this ^^^ remove the extra newline here as it breaks, thanks
> title.style.color='#66'
> } else {
> title.style.color='blue'
> }
> }
> })()
>
>
> marios
>
>>
>> On Tue, Mar 04, at 4:00 pm, Carl Baldwin wrote:
>>
>>> Nachi,
>>>
>>> Great! I'd been meaning to do something like this. I took yours and
>>> tweaked it a bit to highlight failed Jenkins builds in red and grey
>>> other Jenkins messages. Human reviews are left in blue.
>>>
>>> javascript:(function(){
>>> list = document.querySelectorAll('td.GJEA35ODGC');
>>> for(i in list) {
>>> title = list[i];
>>> if(! title.innerHTML) { continue; }
>>> text = title.nextSibling;
>>> if (text.innerHTML.search('Build failed') > 0) {
>>> title.style.color='red'
>>> } else if(title.innerHTML.search('Jenkins|CI|Ryu|Testing|Mine') >=
>>> 0) {
>>> title.style.color='#66'
>>> } else {
>>> title.style.color='blue'
>>> }
>>> }
>>> })()
>>>
>>> Carl
>>>
>>> On Wed, Feb 26, 2014 at 12:31 PM, Nachi Ueno wrote:
>>>> Hi folks
>>>>
>>>> I wrote an bookmarklet for neutron gerrit review.
>>>> This bookmarklet make the comment title for 3rd party ci as gray.
>>>>
>>>> javascript:(function(){list =
>>>> document.querySelectorAll('td.GJEA35ODGC'); for(i in
>>>> list){if(!list[i].innerHTML){continue;};if(list[i].innerHTML &&
>>>> list[i].innerHTML.search('CI|Ryu|Testing|Mine') >
>>>> 0){list[i].style.color='#66'}else{list[i].style.color='red'}};})()
>>>>
>>>> enjoy :)
>>>> Nachi
>>>>
>>>> ___
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev@lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][FYI] Bookmarklet for neutron gerrit review
On 08/05/14 21:29, Henry Gessau wrote:
> Have any of you javascript gurus respun this for the new gerrit version?
> Or can this now be done on the backend somehow?
haha, have been thinking this since the gerrit upgrade a couple days
ago. It was very useful for reviews... I am NOT a javascript guru but
since it's Friday I gave myself 15 minutes to play with it - this works
for me:
javascript:(function(){
list = document.querySelectorAll('table.commentPanelHeader');
for(i in list) {
title = list[i];
if(! title.innerHTML) { continue; }
text = title.nextSibling;
if (text.innerHTML.search('Build failed') > 0) {
title.style.color='red'
} else if(title.innerHTML.search('Jenkins|CI|Ryu|Testing|Mine')
>= 0) {
title.style.color='#66'
} else {
title.style.color='blue'
}
}
})()
marios
>
> On Tue, Mar 04, at 4:00 pm, Carl Baldwin wrote:
>
>> Nachi,
>>
>> Great! I'd been meaning to do something like this. I took yours and
>> tweaked it a bit to highlight failed Jenkins builds in red and grey
>> other Jenkins messages. Human reviews are left in blue.
>>
>> javascript:(function(){
>> list = document.querySelectorAll('td.GJEA35ODGC');
>> for(i in list) {
>> title = list[i];
>> if(! title.innerHTML) { continue; }
>> text = title.nextSibling;
>> if (text.innerHTML.search('Build failed') > 0) {
>> title.style.color='red'
>> } else if(title.innerHTML.search('Jenkins|CI|Ryu|Testing|Mine') >=
>> 0) {
>> title.style.color='#66'
>> } else {
>> title.style.color='blue'
>> }
>> }
>> })()
>>
>> Carl
>>
>> On Wed, Feb 26, 2014 at 12:31 PM, Nachi Ueno wrote:
>>> Hi folks
>>>
>>> I wrote an bookmarklet for neutron gerrit review.
>>> This bookmarklet make the comment title for 3rd party ci as gray.
>>>
>>> javascript:(function(){list =
>>> document.querySelectorAll('td.GJEA35ODGC'); for(i in
>>> list){if(!list[i].innerHTML){continue;};if(list[i].innerHTML &&
>>> list[i].innerHTML.search('CI|Ryu|Testing|Mine') >
>>> 0){list[i].style.color='#66'}else{list[i].style.color='red'}};})()
>>>
>>> enjoy :)
>>> Nachi
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Summit] Neutron etherpad
On 01/05/14 10:47, Roman Podoliaka wrote: > Hi all, > > Following the mailing list thread started by Marios I've put some > initial questions to discuss into this etherpad document: > > https://etherpad.openstack.org/p/juno-summit-tripleo-neutron > > You are encouraged to take a look at it and add your thoughts and/or > questions :) > > Thanks, > Roman Roman thanks so much for picking this up - my mail filters are working a little too well so my apologies for late response. As I said I won't make it to summit this time but will try and follow along and catchup after. Hopefully it will help clarify what we should be looking at in Juno - there are already a whole bunch of HA and/or neutron related patches flying past in the last few weeks [tripleo] so I think a lot of people already have a good idea of what we need to do. The discussion should hopefully be useful to anyone working in or even just interested in this area, thanks, marios > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Flavor(?) Framework
On 24/04/14 13:54, Eugene Nikanorov wrote: > Marios, > > here's the link with proposal description: > https://wiki.openstack.org/wiki/Neutron/FlavorFramework thanks very much (sorry should have found that easily); I'm wondering if the existing blueprint @[1] and (information from) wiki can be combined into a 'new' gerrit based neutron-specs review. I can do that if you would appreciate the help (unless you're already on it). Might even be easier to hash out the naming there. thanks! marios [1] https://blueprints.launchpad.net/neutron/+spec/neutron-flavor-framework http://git.openstack.org/cgit/openstack/neutron-specs > > Mark: personally I find name 'flavor' suitable because it's the same > concept as nova flavor. > So I'll use it in BP/code unless something better come up. > > Thanks, > Eugene. > > > > On Thu, Apr 24, 2014 at 11:09 AM, mar...@redhat.com > wrote: > >> On 23/04/14 18:05, Eugene Nikanorov wrote: >>> Hi neutrons, >>> >>> A quick question of the ^^^ >>> I heard from many of you that a term 'flavor' is undesirable, but so far >>> there were no suggestions for the notion that we are going to introduce. >>> So please, suggest you name for the resource. >>> Names that I've been thinking of: >>> - Capability group >>> - Service Offering >>> >>> Thoughts? >> >> Eugene, my apologies but I am lacking context here - is there a >> discussion/wiki page that may give some background here (what are we >> trying to name? A specific configuration of a neutron deployment? >> >> thanks, marios >> >>> >>> Thanks, >>> Eugene. >>> >>> >>> >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] review hour?
On 24/04/14 10:21, mar...@redhat.com wrote: > Hi, > > > just to wrap this up following discussion during this week's irc meeting > [1] (thanks for bringing it up Kyle) > > I didn't hear any -1 to the general idea of having designated review > times (and quite a few +1). One point raised in the weekly meeting by > Maru Newby was that this may not be effective by itself and that we > should rather choose to assign reviews to core devs for their lifecycle. > This obviously also makes a lot of sense (and perhaps some combination > of the above two would be most effective) - in any case Maru said he'll > have more to say on this proposal at summit. > > So I guess we draw a line under this for the moment. Thanks for your > responses and I'm very happy to see that the community is open to such > discussions/proposals from newcomers and that in general there is > agreement on trying to improve the review process, > > thanks! marios > > [1] > http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-01-06-21.02.log.html > sorry, wrong 21st :) http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-04-21-21.02.log.html > > On 21/04/14 17:38, mar...@redhat.com wrote: >> Hi, >> >> I think both PTL candidates mentioned process improvements wrt >> contributions and reviews in their candidacy announcements. As a new >> Neutron dev I have seen that it is easy for reviews to go unnoticed, >> especially when they are stand-alone bug fixes that aren't part of a >> particular blueprint group (and so aren't discussed/highlighted at the >> various sub-team meetings). Of course this is also compounded by a >> seemingly heavy backlog of reviews. I realise that all core/non-core >> devs are doing as much as they can and though more cores will help, it >> takes a long time to develop people into this role. >> >> I was wondering if a 'review hour' would help. This is something Lucas >> Gomez told me about; the Ironic core team has a weekly hour slot in >> which they discuss x number of reviews and approve or -1 them. Besides >> getting reviews cleared quicker, it also opens the process up. It will >> allow new contributors to (more quickly) learn about the kinds of things >> core reviewers look for in a patch and also give real-time feedback >> (e.g. could just use #openstack-neutron for discussion during the hour). >> I feel that this could have an impact on the review backlog even if this >> only tackling the oldest 5 reviews for example. >> >> Do any of the core devs think this would be a good thing, and do you >> think you have the time for it? >> >> thanks, marios >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] review hour?
Hi, just to wrap this up following discussion during this week's irc meeting [1] (thanks for bringing it up Kyle) I didn't hear any -1 to the general idea of having designated review times (and quite a few +1). One point raised in the weekly meeting by Maru Newby was that this may not be effective by itself and that we should rather choose to assign reviews to core devs for their lifecycle. This obviously also makes a lot of sense (and perhaps some combination of the above two would be most effective) - in any case Maru said he'll have more to say on this proposal at summit. So I guess we draw a line under this for the moment. Thanks for your responses and I'm very happy to see that the community is open to such discussions/proposals from newcomers and that in general there is agreement on trying to improve the review process, thanks! marios [1] http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-01-06-21.02.log.html On 21/04/14 17:38, mar...@redhat.com wrote: > Hi, > > I think both PTL candidates mentioned process improvements wrt > contributions and reviews in their candidacy announcements. As a new > Neutron dev I have seen that it is easy for reviews to go unnoticed, > especially when they are stand-alone bug fixes that aren't part of a > particular blueprint group (and so aren't discussed/highlighted at the > various sub-team meetings). Of course this is also compounded by a > seemingly heavy backlog of reviews. I realise that all core/non-core > devs are doing as much as they can and though more cores will help, it > takes a long time to develop people into this role. > > I was wondering if a 'review hour' would help. This is something Lucas > Gomez told me about; the Ironic core team has a weekly hour slot in > which they discuss x number of reviews and approve or -1 them. Besides > getting reviews cleared quicker, it also opens the process up. It will > allow new contributors to (more quickly) learn about the kinds of things > core reviewers look for in a patch and also give real-time feedback > (e.g. could just use #openstack-neutron for discussion during the hour). > I feel that this could have an impact on the review backlog even if this > only tackling the oldest 5 reviews for example. > > Do any of the core devs think this would be a good thing, and do you > think you have the time for it? > > thanks, marios > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Flavor(?) Framework
On 23/04/14 18:05, Eugene Nikanorov wrote: > Hi neutrons, > > A quick question of the ^^^ > I heard from many of you that a term 'flavor' is undesirable, but so far > there were no suggestions for the notion that we are going to introduce. > So please, suggest you name for the resource. > Names that I've been thinking of: > - Capability group > - Service Offering > > Thoughts? Eugene, my apologies but I am lacking context here - is there a discussion/wiki page that may give some background here (what are we trying to name? A specific configuration of a neutron deployment? thanks, marios > > Thanks, > Eugene. > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] review hour?
On 21/04/14 19:20, Akihiro Motoki wrote: > Hi, > > Previously Neutron team had ReviewDays [1] and core members made themselves > focus on reviews and be available on IRC channel one or more day(s) of each > week > (as possible as they can). > > The number of neutron reviews has increased compared to that time and > I am afraid one or two days reviews cannot deal with neutron reviews, but > the similar mechanism might work to make things better. > > [1] https://wiki.openstack.org/wiki/Neutron/ReviewDays Akihiro thanks very much for sharing this link. I searched through openstack-dev for a discussion but missed the wiki :/ This is great - it makes more sense since as far as I can see the community is really distributed and so it is difficult for all cores to have consensus on a suitable time. As long as there is a minimum of 2 cores and any number of interested non-core (so that patches can actually get pushed where possible). The downside is losing the '2 meeting slots' advantage though I guess that really is a separate issue (weekly meeting time slot convenience?) that folks may i) agree/disagree is valid and ii) can be discussed as such. thanks! marios > > > On Tue, Apr 22, 2014 at 12:54 AM, mar...@redhat.com > wrote: >> On 21/04/14 18:29, Kyle Mestery wrote: >>> On Mon, Apr 21, 2014 at 9:38 AM, mar...@redhat.com >>> wrote: >>>> Hi, >>>> >>>> I think both PTL candidates mentioned process improvements wrt >>>> contributions and reviews in their candidacy announcements. As a new >>>> Neutron dev I have seen that it is easy for reviews to go unnoticed, >>>> especially when they are stand-alone bug fixes that aren't part of a >>>> particular blueprint group (and so aren't discussed/highlighted at the >>>> various sub-team meetings). Of course this is also compounded by a >>>> seemingly heavy backlog of reviews. I realise that all core/non-core >>>> devs are doing as much as they can and though more cores will help, it >>>> takes a long time to develop people into this role. >>>> >>>> I was wondering if a 'review hour' would help. This is something Lucas >>>> Gomez told me about; the Ironic core team has a weekly hour slot in >>>> which they discuss x number of reviews and approve or -1 them. Besides >>>> getting reviews cleared quicker, it also opens the process up. It will >>>> allow new contributors to (more quickly) learn about the kinds of things >>>> core reviewers look for in a patch and also give real-time feedback >>>> (e.g. could just use #openstack-neutron for discussion during the hour). >>>> I feel that this could have an impact on the review backlog even if this >>>> only tackling the oldest 5 reviews for example. >>>> >>>> Do any of the core devs think this would be a good thing, and do you >>>> think you have the time for it? >>>> >>> This is an interesting idea Marios, thanks for proposing it! Are you >>> saying we should have a "Review Hour" on IRC, where we walk through XX >>> number of reviews as a team? That's an interesting idea actually, and >>> I'd be in favor of something like this. We could rotate timeslots so >>> as to get everyone on the team (both core and non-core) a chance to >>> participate. >>> >>> Can you attend our weekly meeting today [1] where we can discuss this as a >>> team? >> >> Thanks very much for responding Kyle, I was worried about my message >> sounding 'complainy' - I will try my best to attend the meeting today, >> though it is at midnight here (CET +1hrs) so I typically only get to >> catch up on the logs. >> >> Depending on whether others think setting up the "irc review hour" is a >> good idea, one side effect would be that we then have a second 'neutron >> meeting' slot during the week (even if this is only for reviews). If we >> pick this time carefully we could even alternate between 'weekly >> meeting' and 'review meeting' to make it easier for folks in Europe to >> join the weekly meeting (and make it less harsh for people in Asia >> Pacific who have to get up very early for the current slot [1]). Though >> this is of course just speculation and I'm really getting ahead of >> myself (I was going to include this last thought in my original email >> but it was already long enough) >> >> thanks, marios >> >> >> [1] [1] >> http://www.timeanddate.com/wor
Re: [openstack-dev] [Neutron] review hour?
On 21/04/14 18:29, Kyle Mestery wrote: > On Mon, Apr 21, 2014 at 9:38 AM, mar...@redhat.com > wrote: >> Hi, >> >> I think both PTL candidates mentioned process improvements wrt >> contributions and reviews in their candidacy announcements. As a new >> Neutron dev I have seen that it is easy for reviews to go unnoticed, >> especially when they are stand-alone bug fixes that aren't part of a >> particular blueprint group (and so aren't discussed/highlighted at the >> various sub-team meetings). Of course this is also compounded by a >> seemingly heavy backlog of reviews. I realise that all core/non-core >> devs are doing as much as they can and though more cores will help, it >> takes a long time to develop people into this role. >> >> I was wondering if a 'review hour' would help. This is something Lucas >> Gomez told me about; the Ironic core team has a weekly hour slot in >> which they discuss x number of reviews and approve or -1 them. Besides >> getting reviews cleared quicker, it also opens the process up. It will >> allow new contributors to (more quickly) learn about the kinds of things >> core reviewers look for in a patch and also give real-time feedback >> (e.g. could just use #openstack-neutron for discussion during the hour). >> I feel that this could have an impact on the review backlog even if this >> only tackling the oldest 5 reviews for example. >> >> Do any of the core devs think this would be a good thing, and do you >> think you have the time for it? >> > This is an interesting idea Marios, thanks for proposing it! Are you > saying we should have a "Review Hour" on IRC, where we walk through XX > number of reviews as a team? That's an interesting idea actually, and > I'd be in favor of something like this. We could rotate timeslots so > as to get everyone on the team (both core and non-core) a chance to > participate. > > Can you attend our weekly meeting today [1] where we can discuss this as a > team? Thanks very much for responding Kyle, I was worried about my message sounding 'complainy' - I will try my best to attend the meeting today, though it is at midnight here (CET +1hrs) so I typically only get to catch up on the logs. Depending on whether others think setting up the "irc review hour" is a good idea, one side effect would be that we then have a second 'neutron meeting' slot during the week (even if this is only for reviews). If we pick this time carefully we could even alternate between 'weekly meeting' and 'review meeting' to make it easier for folks in Europe to join the weekly meeting (and make it less harsh for people in Asia Pacific who have to get up very early for the current slot [1]). Though this is of course just speculation and I'm really getting ahead of myself (I was going to include this last thought in my original email but it was already long enough) thanks, marios [1] [1] http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140421&p1=137&p2=179&p3=136&p4=37&p5=166&p6=248&p7=196&p8=47 > > Thanks! > Kyle > > [1] https://wiki.openstack.org/wiki/Network/Meetings > >> thanks, marios >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] review hour?
Hi, I think both PTL candidates mentioned process improvements wrt contributions and reviews in their candidacy announcements. As a new Neutron dev I have seen that it is easy for reviews to go unnoticed, especially when they are stand-alone bug fixes that aren't part of a particular blueprint group (and so aren't discussed/highlighted at the various sub-team meetings). Of course this is also compounded by a seemingly heavy backlog of reviews. I realise that all core/non-core devs are doing as much as they can and though more cores will help, it takes a long time to develop people into this role. I was wondering if a 'review hour' would help. This is something Lucas Gomez told me about; the Ironic core team has a weekly hour slot in which they discuss x number of reviews and approve or -1 them. Besides getting reviews cleared quicker, it also opens the process up. It will allow new contributors to (more quickly) learn about the kinds of things core reviewers look for in a patch and also give real-time feedback (e.g. could just use #openstack-neutron for discussion during the hour). I feel that this could have an impact on the review backlog even if this only tackling the oldest 5 reviews for example. Do any of the core devs think this would be a good thing, and do you think you have the time for it? thanks, marios ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][design] review based conceptual design process
On 15/04/14 20:44, Robert Collins wrote: > I've been watching the nova process, and I think its working out well > - it certainly addresses: > - making design work visible > - being able to tell who has had input > - and providing clear feedback to the designers > > I'd like to do the same thing for TripleO this cycle.. > > I'm thinking we can just add docs to incubator, since thats already a > repository separate to our production code - what do folk think? > > -Rob > Nova (and now Neutron too) has documented their process at https://wiki.openstack.org/wiki/Blueprints#Nova ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Neutron BP review process for Juno
On 16/04/14 00:07, Kyle Mestery wrote: > Given the success the Nova team has had in handling reviews using > their new nova-specs gerrit repository, I think it makes a lot of > sense for Neutron to do the same. With this in mind, I've added > instructions to the BP wiki [1] for how to do. Going forward in Juno, fwiw, tripleo is discussing the adoption of this practice for the coming cycle (and looks very likely to do so) marios > this is how Neutron BPs will be handled by the Neutron core team. If > you are currently working on a BP or code for Juno which is attached > to a BP, please file the BP using the process here [1]. > > Given this is our first attempt at using this for reviews, I > anticipate there may be a few hiccups along the way. Please reply on > this thread or reach out in #openstack-neutron and we'll sort through > whatever issues we find. > > Thanks! > Kyle > > [1] https://wiki.openstack.org/wiki/Blueprints#Neutron > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][design] review based conceptual design process
On 15/04/14 21:54, Ben Nemec wrote: > On 04/15/2014 01:44 PM, Robert Collins wrote: >> I've been watching the nova process, and I think its working out well >> - it certainly addresses: >> - making design work visible >> - being able to tell who has had input >> - and providing clear feedback to the designers >> >> I'd like to do the same thing for TripleO this cycle.. >> >> I'm thinking we can just add docs to incubator, since thats already a >> repository separate to our production code - what do folk think? >> >> -Rob >> > > +1 from me. We've also been planning to adopt this for Oslo. > > For anyone who hasn't been following the Nova discussion, here's a link > to the original proposal: > http://lists.openstack.org/pipermail/openstack-dev/2014-March/029232.html thanks Ben, this was useful to understand what was being proposed here. +1 from me fwiw and I also agree with others that it will be cleaner to have a stand-alone specs repo, thanks, marios > > There's also the more recent thread Monty referenced: > http://lists.openstack.org/pipermail/openstack-dev/2014-April/032753.html > > -Ben > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] new contributor failing tests - help!
On 14/04/14 19:51, Kevin Benton wrote:
> Hi Mario,
>
> Here is the problem:
>>>> import netaddr
>>>> p = netaddr.IPNetwork('2001:0db8::/64')
>>>> str(p)
> '2001:db8::/64'
>
> Now that you are converting CIDR strings to netaddr objects and back, it's
> causing redundant info to be dropped. You will just have to remove the
> references to 2001:0db8::/64 and replace them with 2001:db8::/64.
thanks so much! This did it and the tests now pass ok. When we meet (I
won't be at Atlanta unfortunately, hopefully next one) I owe you at
*least* one beer ;)
thanks, marios
>
> I will comment on the review as well.
>
> Cheers,
> Kevin Benton
>
>
> On Mon, Apr 14, 2014 at 9:23 AM, mar...@redhat.com wrote:
>
>> Hi,
>>
>> I am really stumped by a Jenkins failure for one of my reviews... @
>> https://review.openstack.org/#/c/59212/ if any kind soul has any
>> pointers/help I will be very grateful. The strange thing is that Jenkins
>> +1 this patchset (Apr 2) but subsequently failed as described below:
>>
>> The failure is from
>>
>> neutron.tests.unit.test_security_groups_rpc.SGServerRpcCallBackMixinTestCase
>> and specifically the 2 test cases
>> test_security_group_rules_for_devices_ipv6_ingress and
>> test_security_group_rules_for_devices_ipv6_egress
>>
>> The failure is on the assertion at the end of the methods:
>>
>> self.assertEqual(port_rpc['security_group_rules'],expected)
>>
>> port_rpc['security_group_rules'] ---> {'ethertype': u'IPv6',
>> 'direction': u'egress'
>> expected ---> {'ethertype': 'IPv6', 'direction':
>> 'egress'
>>
>> (you can see this in the logs, e.g.
>>
>> http://logs.openstack.org/12/59212/14/check/gate-neutron-python27/57d89d5/console.html.gz
>> )
>>
>>
>> I have *no* idea what in my code is causing this behaviour; if I just
>> grab this review, the tests pass fine. But if I rebase against master,
>> they fail, i.e.:
>>
>> git review -d I71fb8c887963a122a5bd8cfdda800026c1cd3954
>> source .tox/py27/bin/activate
>> ./run_tests.sh -d
>>
>> neutron.tests.unit.test_security_groups_rpc.SGServerRpcCallBackMixinTestCase
>>
>> ...
>>
>> Ran 7 tests in 1.926s
>> OK
>>
>> ...
>>
>> git rebase master
>> ./run_tests.sh -d
>>
>> neutron.tests.unit.test_security_groups_rpc.SGServerRpcCallBackMixinTestCase
>>
>> ...
>>
>> Ran 11 tests in 2.964s
>> FAILED (failures=2)
>>
>> ...
>>
>> thanks for reading, if you came this far!
>>
>> marios
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron] new contributor failing tests - help!
Hi,
I am really stumped by a Jenkins failure for one of my reviews... @
https://review.openstack.org/#/c/59212/ if any kind soul has any
pointers/help I will be very grateful. The strange thing is that Jenkins
+1 this patchset (Apr 2) but subsequently failed as described below:
The failure is from
neutron.tests.unit.test_security_groups_rpc.SGServerRpcCallBackMixinTestCase
and specifically the 2 test cases
test_security_group_rules_for_devices_ipv6_ingress and
test_security_group_rules_for_devices_ipv6_egress
The failure is on the assertion at the end of the methods:
self.assertEqual(port_rpc['security_group_rules'],expected)
port_rpc['security_group_rules'] ---> {'ethertype': u'IPv6',
'direction': u'egress'
expected ---> {'ethertype': 'IPv6', 'direction':
'egress'
(you can see this in the logs, e.g.
http://logs.openstack.org/12/59212/14/check/gate-neutron-python27/57d89d5/console.html.gz)
I have *no* idea what in my code is causing this behaviour; if I just
grab this review, the tests pass fine. But if I rebase against master,
they fail, i.e.:
git review -d I71fb8c887963a122a5bd8cfdda800026c1cd3954
source .tox/py27/bin/activate
./run_tests.sh -d
neutron.tests.unit.test_security_groups_rpc.SGServerRpcCallBackMixinTestCase
...
Ran 7 tests in 1.926s
OK
...
git rebase master
./run_tests.sh -d
neutron.tests.unit.test_security_groups_rpc.SGServerRpcCallBackMixinTestCase
...
Ran 11 tests in 2.964s
FAILED (failures=2)
...
thanks for reading, if you came this far!
marios
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] [Horizon] Icehouse Release of TripleO UI + Demo
On 11/04/14 10:35, Ladislav Smola wrote: > Hello, > > we have used this list of steps for the demo on Fedora 20: > https://wiki.openstack.org/wiki/Tuskar/Devtest nice! > > The demo is running on one machine with 24GB RAM and 120GB disk. We are > using > virtualized baremetals(bm_poseur) for development. > > KInd Regards, > Ladislav > > > On 04/10/2014 07:40 PM, Nachi Ueno wrote: >> Hi Jarda >> >> Congratulations >> This release and the demo is super awesome!! >> Do you have any instruction to install this one? >> >> >> >> >> 2014-04-10 1:32 GMT-07:00 Jaromir Coufal : >>> Dear Stackers, >>> >>> I am happy to announce that yesterday Tuskar UI (TripleO UI) has tagged >>> branch 0.1.0 for Icehouse release [0]. >>> >>> I put together a narrated demo of all included features [1]. >>> >>> You can find one manual part in the whole workflow - cloud >>> initialization. >>> There is ongoing work on automatic os-cloud-config, but for the >>> release we >>> had to include manual way. Automation should be added soon though. >>> >>> I want to thank all contributors for hard work to make this happen. >>> It has >>> been pleasure to cooperate with all of you guys and I am looking >>> forward to >>> bringing new features [2] in. >>> >>> >>> -- Jarda >>> >>> >>> [0] 0.1.0 Icehouse Release of the UI: >>> https://github.com/openstack/tuskar-ui/releases/tag/0.1.0 >>> >>> [1] Narrated demo of TripleO UI 0.1.0: >>> https://www.youtube.com/watch?v=-6whFIqCqLU >>> >>> [2] Juno Planning for Tuskar: >>> https://wiki.openstack.org/wiki/TripleO/TuskarJunoPlanning >>> >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Tuskar] [Horizon] Icehouse Release of TripleO UI + Demo
On 10/04/14 20:55, Jay Dobies wrote: > On 04/10/2014 01:40 PM, Nachi Ueno wrote: >> Hi Jarda >> >> Congratulations >> This release and the demo is super awesome!! >> Do you have any instruction to install this one? > > I'd like to see this too. I asked a few times and never got an answer on > whether or not there was a documented way of demoing this without a ton > of baremetal lying around. from what Jarda said in his other email (un-narrated one), this is all running from master. In which case all you need is an undercloud setup and then you can install tuskar/ui on that host. WRT the baremetal - For dev I've only ever done this with poseur nodes - or I misunderstood the question marios > >> >> >> >> 2014-04-10 1:32 GMT-07:00 Jaromir Coufal : >>> Dear Stackers, >>> >>> I am happy to announce that yesterday Tuskar UI (TripleO UI) has tagged >>> branch 0.1.0 for Icehouse release [0]. >>> >>> I put together a narrated demo of all included features [1]. >>> >>> You can find one manual part in the whole workflow - cloud >>> initialization. >>> There is ongoing work on automatic os-cloud-config, but for the >>> release we >>> had to include manual way. Automation should be added soon though. >>> >>> I want to thank all contributors for hard work to make this happen. >>> It has >>> been pleasure to cooperate with all of you guys and I am looking >>> forward to >>> bringing new features [2] in. >>> >>> >>> -- Jarda >>> >>> >>> [0] 0.1.0 Icehouse Release of the UI: >>> https://github.com/openstack/tuskar-ui/releases/tag/0.1.0 >>> >>> [1] Narrated demo of TripleO UI 0.1.0: >>> https://www.youtube.com/watch?v=-6whFIqCqLU >>> >>> [2] Juno Planning for Tuskar: >>> https://wiki.openstack.org/wiki/TripleO/TuskarJunoPlanning >>> >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] [TripleO] [Tuskar] Demo of current state of "Tuskar-UI"
On 09/04/14 16:54, Jaromir Coufal wrote: > Hello OpenStackers, > > I would like to share with you non-narrated demo of current version of > 'Tuskar-UI' project, which is very close to Icehouse release (one or two > more patches to come in). > > Tuskar-UI is a user interface based on TripleO approach which allows > user to register nodes (currently nova-baremetal -> ironic), define > hardware profiles (nova-flavors), design OpenStack deployment (Tuskar) > and based on HW profiles to deploy OpenStack on your baremetal nodes > (Heat). > > Demo: https://www.youtube.com/watch?v=3_u2PmeF36k > > Juno roadmap - Tuskar planning for J cycle: > https://wiki.openstack.org/wiki/TripleO/TuskarJunoPlanning > > If you have any questions, we are happy to help you. Just ask here on > the mailing list, or you can find many folks on following channels: > #tuskar, #tripleo, #openstack-horizon (UI related channel) > > Cheers > -- Jarda Jarda thanks this was great to watch - seems a lot of things have been fixed/tweaked in last couple weeks. Is everything running from current master branches? marios > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] reviewer update march [additional cores]
On 08/04/14 02:50, Robert Collins wrote: > tl;dr: 3 more core members to propose: > bnemec > greghaynes > jdon > +1 > > On 4 April 2014 08:55, Chris Jones wrote: >> Hi >> >> +1 for your proposed -core changes. >> >> Re your question about whether we should retroactively apply the 3-a-day >> rule to the 3 month review stats, my suggestion would be a qualified no. >> >> I think we've established an agile approach to the member list of -core, so >> if there are a one or two people who we would have added to -core before the >> goalposts moved, I'd say look at their review quality. If they're showing >> the right stuff, let's get them in and helping. If they don't feel our new >> goalposts are achievable with their workload, they'll fall out again >> naturally before long. > > So I've actioned the prior vote. > > I said: "Bnemec, jdob, greg etc - good stuff, I value your reviews > already, but..." > > So... looking at a few things - long period of reviews: > 60 days: > |greghaynes | 1210 22 99 0 081.8% | > 14 ( 11.6%) | > | bnemec | 1160 38 78 0 067.2% | > 10 ( 8.6%) | > | jdob | 870 15 72 0 082.8% | > 4 ( 4.6%) | > > 90 days: > > | bnemec | 1450 40 105 0 072.4% | > 17 ( 11.7%) | > |greghaynes | 1420 23 119 0 083.8% | > 22 ( 15.5%) | > | jdob | 1060 17 89 0 084.0% | > 7 ( 6.6%) | > > Ben's reviews are thorough, he reviews across all contributors, he > shows good depth of knowledge and awareness across tripleo, and is > sensitive to the pragmatic balance between 'right' and 'good enough'. > I'm delighted to support him for core now. > > Greg is very active, reviewing across all contributors with pretty > good knowledge and awareness. I'd like to see a little more contextual > awareness though - theres a few (but not many) reviews where looking > at how the big picture of things fitting together more would have been > beneficial. *however*, I think that's a room-to-improve issue vs > not-good-enough-for-core - to me it makes sense to propose him for > core too. > > Jay's reviews are also very good and consistent, somewhere between > Greg and Ben in terms of bigger-context awareness - so another > definite +1 from me. > > -Rob > > > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Tripleo][Neutron] Tripleo & Neutron
On 07/04/14 15:56, Dmitriy Shulyak wrote: > Hi Marios, thanks for raising this. > > There is in progress blueprint that should address some issues with neutron > ha deployment - > https://blueprints.launchpad.net/neutron/+spec/l3-high-availability. > > Right now neutron-dhcp agent can be configured as active/active. > > But l3-agent and metadata-agent still should be active/passive, > afaik the best approach would be to use corosync+pacemaker, that is also > stated in official documentation > http://docs.openstack.org/high-availability-guide/content/ch-network.html. > > What other choices, except corosync+pacemaker, do we have for neutron ha? thanks for the pointers Dmitriy! Perhaps this can be discussed if a discussion/session is put together at summit as suggested by Roman marios > > Thanks > > > > On Mon, Apr 7, 2014 at 11:18 AM, mar...@redhat.com wrote: > >> Hello Tripleo/Neutron: >> >> I've recently found some cycles to look into Neutron. Mostly because >> networking rocks, but also so we can perhaps better address Neutron >> related issues/needs down the line. I thought it may be good to ask the >> wider team if there are others that are also interested in >> Neutron&Tripleo. We could form a loose focus group to discuss blueprints >> and review each other's code/chase up with cores. My search may have >> missed earlier discussions in openstack-dev[Tripleo][Neutron] and >> Tripleo bluprints so my apologies if this has already been started >> somewhere. If any of the above is of interest then: >> >> *is the following list sane - does it make sense to pick these off or >> are these 'nice to haves' but not of immediate concern? Even just >> validating, prioritizing and recording concerns could be worthwhile for >> example? >> * are you interested in discussing any of the following further and >> perhaps investigating and/or helping with blueprints where/if necessary? >> >> Right now I have: >> >> [Undercloud]: >> >> 1. Define a neutron node (tripleo-image-elements/disk-image-builder) and >> make sure it deploys and scales ok (tripleo-heat-templates/tuskar). This >> comes under by lifeless blueprint at >> >> https://blueprints.launchpad.net/tripleo/+spec/tripleo-tuskar-deployment-scaling-topologies >> >> 2. HA the neutron node. For each neutron services/agents of interest >> (neutron-dhcp-agent, neutron-l3-agent, neutron-lbaas-agent ... ) fix any >> issues with running these in HA - perhaps there are none \o/? Useful >> whether using a dedicated Neutron node or just for HA the >> undercloud-control node >> >> 3. Does it play with Ironic OK? I know there were some issues with >> Ironic and Neutron DHCP, though I think this has now been addressed. >> Other known/unkown bugs/issues with Ironic/Neutron - the baremetal >> driver will be deprecated at some point... >> >> 4. Subnetting. Right now the undercloud uses a single subnet. Does it >> make sense to have multiple subnets here - one point I've heard is for >> segregation of your undercloud nodes (i.e. <1 broadcast domain). >> >> 5. Security. Are we at least using Neutron as we should be in the >> Undercloud, security-groups, firewall rules etc? >> >> [Overcloud]: >> >> 1. Configuration. In the overcloud "it's just Neutron". So one concern >> is which and how to expose neutron configuration options via Tuskar-UI. >> We would pass these through the deployment heat-template for definition >> of Neutron plugin-specific .conf files (like dnsmasq-neutron.conf) for >> example or initial definition of tenant subnets and router(s) for access >> to external networks. >> >> 2. 3. ??? >> >> >> thanks! marios >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Tripleo][Neutron] Tripleo & Neutron
On 07/04/14 16:49, Roman Podoliaka wrote: > Hi all, > > Perhaps, we should file a design session for Neutron-specific questions? that's a good idea - unfortunately I won't be at summit... if there is more interest and you do go ahead with this please let me know I will try and join by hangout for example. > 1. Define a neutron node (tripleo-image-elements/disk-image-builder) and make sure it deploys and scales ok (tripleo-heat-templates/tuskar). This comes under by lifeless blueprint at https://blueprints.launchpad.net/tripleo/+spec/tripleo-tuskar-deployment-scaling-topologies > > As far as I understand, this must be pretty straightforward: just > reuse the neutron elements we need when building an image for a > neutron node. Right - not all of these points I listed need blueprints (or perhaps none ;) ) but for many it will be just verification that 'it works'... I agree that we should just be able to build the image with whichever neutron services we need there. I expect that getting the plumbing right may be the issue here (heat template params, credentials, database etc) > 2. HA the neutron node. For each neutron services/agents of interest (neutron-dhcp-agent, neutron-l3-agent, neutron-lbaas-agent ... ) fix any issues with running these in HA - perhaps there are none \o/? Useful whether using a dedicated Neutron node or just for HA the undercloud-control node > > - HA for DHCP-agent is provided out-of-box - we can just use > 'dhcp_agents_per_network' option > (https://github.com/openstack/tripleo-image-elements/blob/master/elements/neutron/os-apply-config/etc/neutron/neutron.conf#L59) > > - for L3-agent there is a BP started, but the patches haven't been > merged yet - > https://blueprints.launchpad.net/neutron/+spec/l3-high-availability thanks! Seems I am the only one that didn't know of this blueprint :) > > - API must be no different from other API services we have not sure what that means ^^^ > 3. Does it play with Ironic OK? I know there were some issues with Ironic and Neutron DHCP, though I think this has now been addressed. Other known/unkown bugs/issues with Ironic/Neutron - the baremetal driver will be deprecated at some point... > > You must be talking about specifying PXE boot options by the means of > neutron-dhcp-agent. Yes, this has been merged to Neutron for a while > now (https://review.openstack.org/#/c/30441/). thanks - not sure if that was it as the issues I heard about were more recent than that (from colleagues working on that, I could chase up specifics if necessary). In any case my point was rather more general... Ironic is obviously still new and so are there any current known or expected issues we need to deal with thanks, marios > > Thanks, > Roman > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Tripleo][Neutron] Tripleo & Neutron
On 07/04/14 18:05, Jan Provazník wrote: > On 04/07/2014 03:49 PM, Roman Podoliaka wrote: > 2. HA the neutron node. For each neutron services/agents of > interest (neutron-dhcp-agent, neutron-l3-agent, > neutron-lbaas-agent ... ) fix any issues with running these in > HA - perhaps there are none \o/? Useful whether using a > dedicated Neutron node or just for HA the undercloud-control > node >> >> - HA for DHCP-agent is provided out-of-box - we can just use >> 'dhcp_agents_per_network' option >> (https://github.com/openstack/tripleo-image-elements/blob/master/elements/neutron/os-apply-config/etc/neutron/neutron.conf#L59) >> >> >> - for L3-agent there is a BP started, but the patches haven't been >> merged yet - >> https://blueprints.launchpad.net/neutron/+spec/l3-high-availability >> > > Right, though a patch which adds A/A for L3 agent has already been sent: > https://review.openstack.org/#/c/64553/ so we might test how it works. > > There is a trello card for Neutron HA here: > https://trello.com/c/DaIs1zxb/82-neutron-ha-redundant-environment thanks for the pointers Jan! > > > To add more questions: > Would it be possible to use Neutron's LBaaS in TripleO (which is the > long-term plan) and what are missing bits? Good question - you told me you had heard of 'technical issues' with baremetal... does anyone know if these still exist with Ironic? I guess another point for investigation. > > And (maybe trivial) question: > for present time (when we don't use Neutron's LBaaS), is there a simple > way how to get virtual IPs from Neutron? We set up haproxy in overcloud > controller nodes, but we need to allocate virtual IP pointing to haproxy. I don't know, perhaps others can chime in here (enikanorov may be the person to ask here - he is the lead for the lbaas subteam) thanks, marios > > Jan > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Heat] TripleO Heat Templates and merge.py
On 07/04/14 00:27, Steve Baker wrote:
> On 05/04/14 04:47, Tomas Sedovic wrote:
>> Hi All,
>>
>> I was wondering if the time has come to document what exactly are we
>> doing with tripleo-heat-templates and merge.py[1], figure out what needs
>> to happen to move away and raise the necessary blueprints on Heat and
>> TripleO side.
>>
>> (merge.py is a script we use to build the final TripleO Heat templates
>> from smaller chunks)
>>
>> There probably isn't an immediate need for us to drop merge.py, but its
>> existence either indicates deficiencies within Heat or our unfamiliarity
>> with some of Heat's features (possibly both).
>>
>> I worry that the longer we stay with merge.py the harder it will be to
>> move forward. We're still adding new features and fixing bugs in it (at
>> a slow pace but still).
>>
>> Below is my understanding of the main marge.py functionality and a rough
>> plan of what I think might be a good direction to move to. It is almost
>> certainly incomplete -- please do poke holes in this. I'm hoping we'll
>> get to a point where everyone's clear on what exactly merge.py does and
>> why. We can then document that and raise the appropriate blueprints.
>>
>>
>> ## merge.py features ##
>>
>>
>> 1. Merging parameters and resources
>>
>> Any uniquely-named parameters and resources from multiple templates are
>> put together into the final template.
>>
>> If a resource of the same name is in multiple templates, an error is
>> raised. Unless it's of a whitelisted type (nova server, launch
>> configuration, etc.) in which case they're all merged into a single
>> resource.
>>
>> For example: merge.py overcloud-source.yaml swift-source.yaml
>>
>> The final template has all the parameters from both. Moreover, these two
>> resources will be joined together:
>>
>> overcloud-source.yaml
>>
>> notCompute0Config:
>> Type: AWS::AutoScaling::LaunchConfiguration
>> Properties:
>> ImageId: '0'
>> InstanceType: '0'
>> Metadata:
>> admin-password: {Ref: AdminPassword}
>> admin-token: {Ref: AdminToken}
>> bootstack:
>> public_interface_ip:
>> Ref: NeutronPublicInterfaceIP
>>
>>
>> swift-source.yaml
>>
>> notCompute0Config:
>> Type: AWS::AutoScaling::LaunchConfiguration
>> Metadata:
>> swift:
>> devices:
>> ...
>> hash: {Ref: SwiftHashSuffix}
>> service-password: {Ref: SwiftPassword}
>>
>>
>> The final template will contain:
>>
>> notCompute0Config:
>> Type: AWS::AutoScaling::LaunchConfiguration
>> Properties:
>> ImageId: '0'
>> InstanceType: '0'
>> Metadata:
>> admin-password: {Ref: AdminPassword}
>> admin-token: {Ref: AdminToken}
>> bootstack:
>> public_interface_ip:
>> Ref: NeutronPublicInterfaceIP
>> swift:
>> devices:
>> ...
>> hash: {Ref: SwiftHashSuffix}
>> service-password: {Ref: SwiftPassword}
>>
>>
>> We use this to keep the templates more manageable (instead of having one
>> huge file) and also to be able to pick the components we want: instead
>> of `undercloud-bm-source.yaml` we can pick `undercloud-vm-source` (which
>> uses the VirtualPowerManager driver) or `ironic-vm-source`.
>>
>>
>>
>> 2. FileInclude
>>
>> If you have a pseudo resource with the type of `FileInclude`, we will
>> look at the specified Path and SubKey and put the resulting dictionary in:
>>
>> overcloud-source.yaml
>>
>> NovaCompute0Config:
>> Type: FileInclude
>> Path: nova-compute-instance.yaml
>> SubKey: Resources.NovaCompute0Config
>> Parameters:
>> NeutronNetworkType: "gre"
>> NeutronEnableTunnelling: "True"
>>
>>
>> nova-compute-instance.yaml
>>
>> NovaCompute0Config:
>> Type: AWS::AutoScaling::LaunchConfiguration
>> Properties:
>> InstanceType: '0'
>> ImageId: '0'
>> Metadata:
>> keystone:
>> host: {Ref: KeystoneHost}
>> neutron:
>> host: {Ref: NeutronHost}
>> tenant_network_type: {Ref: NeutronNetworkType}
>> network_vlan_ranges: {Ref: NeutronNetworkVLANRanges}
>> bridge_mappings: {Ref: NeutronBridgeMappings}
>> enable_tunneling: {Ref: NeutronEnableTunnelling}
>> physical_bridge: {Ref: NeutronPhysicalBridge}
>> public_interface: {Ref: NeutronPublicInterface}
>> service-password:
>> Ref: NeutronPassword
>> admin-password: {Ref: AdminPassword}
>>
>> The result:
>>
>> NovaCompute0Config:
>> Type: AWS::AutoScaling::LaunchConfiguration
>> Properties:
>> InstanceType: '0'
>> ImageId: '0'
>> Metadata:
>> keystone:
>> host: {Ref: KeystoneHost}
>> neutron:
>> host: {Ref: NeutronHost}
>> tenant_network_type: "gre"
>> network_vlan_ranges: {Ref: NeutronNetworkVLANRanges}
>> bridge_mappings: {Ref: NeutronBridgeMappings}
>> enab
[openstack-dev] [Tripleo][Neutron] Tripleo & Neutron
Hello Tripleo/Neutron: I've recently found some cycles to look into Neutron. Mostly because networking rocks, but also so we can perhaps better address Neutron related issues/needs down the line. I thought it may be good to ask the wider team if there are others that are also interested in Neutron&Tripleo. We could form a loose focus group to discuss blueprints and review each other's code/chase up with cores. My search may have missed earlier discussions in openstack-dev[Tripleo][Neutron] and Tripleo bluprints so my apologies if this has already been started somewhere. If any of the above is of interest then: *is the following list sane - does it make sense to pick these off or are these 'nice to haves' but not of immediate concern? Even just validating, prioritizing and recording concerns could be worthwhile for example? * are you interested in discussing any of the following further and perhaps investigating and/or helping with blueprints where/if necessary? Right now I have: [Undercloud]: 1. Define a neutron node (tripleo-image-elements/disk-image-builder) and make sure it deploys and scales ok (tripleo-heat-templates/tuskar). This comes under by lifeless blueprint at https://blueprints.launchpad.net/tripleo/+spec/tripleo-tuskar-deployment-scaling-topologies 2. HA the neutron node. For each neutron services/agents of interest (neutron-dhcp-agent, neutron-l3-agent, neutron-lbaas-agent ... ) fix any issues with running these in HA - perhaps there are none \o/? Useful whether using a dedicated Neutron node or just for HA the undercloud-control node 3. Does it play with Ironic OK? I know there were some issues with Ironic and Neutron DHCP, though I think this has now been addressed. Other known/unkown bugs/issues with Ironic/Neutron - the baremetal driver will be deprecated at some point... 4. Subnetting. Right now the undercloud uses a single subnet. Does it make sense to have multiple subnets here - one point I've heard is for segregation of your undercloud nodes (i.e. <1 broadcast domain). 5. Security. Are we at least using Neutron as we should be in the Undercloud, security-groups, firewall rules etc? [Overcloud]: 1. Configuration. In the overcloud "it's just Neutron". So one concern is which and how to expose neutron configuration options via Tuskar-UI. We would pass these through the deployment heat-template for definition of Neutron plugin-specific .conf files (like dnsmasq-neutron.conf) for example or initial definition of tenant subnets and router(s) for access to external networks. 2. 3. ??? thanks! marios ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] reviewer update march
On 03/04/14 14:02, Robert Collins wrote: > Getting back in the swing of things... > > Hi, > like most OpenStack projects we need to keep the core team up to > date: folk who are not regularly reviewing will lose context over > time, and new folk who have been reviewing regularly should be trusted > with -core responsibilities. > > In this months review: > - Dan Prince for -core > - Jordan O'Mara for removal from -core > - Jiri Tomasek for removal from -core > - Jamomir Coufal for removal from -core +1 > > Existing -core members are eligible to vote - please indicate your > opinion on each of the three changes above in reply to this email. > <---snip> > > -core that are not keeping up recently... : > > | tomas-8c8 ** | 310 4 2 25 887.1% | > 1 ( 3.2%) | > |marios **| 270 1 17 9 796.3% | > 3 ( 11.1%) | thanks for the heads up - after some time away, I've been keeping the '3 a day' for the last couple weeks so hopefully this will improve. However, my reviews are mainly in tripleo-heat-templates and tuskar-ui; I guess the latter no longer counts towards these statistics (under horizon?) and I'm not sure how to reconcile this ...? Should I just drop the tuskar-ui reviews altogether ( I am trying to become more active in neutron too, so something has to give somewhere)... thanks! marios > | tzumainn ** | 270 3 23 1 488.9% | > 0 ( 0.0%) | > |pblaho **| 170 0 4 13 4 100.0% | > 1 ( 5.9%) | > |jomara **| 00 0 0 0 1 0.0% | > 0 ( 0.0%) | > > > Please remember - the stats are just an entry point to a more detailed > discussion about each individual, and I know we all have a bunch of > work stuff, on an ongoing basis :) > > I'm using the fairly simple metric we agreed on - 'average at least > three reviews a > day' as a proxy for 'sees enough of the code and enough discussion of > the code to be an effective reviewer'. The three review a day thing we > derived based > on the need for consistent volume of reviews to handle current > contributors - we may > lower that once we're ahead (which may happen quickly if we get more cores... > :) > But even so: > - reading three patches a day is a pretty low commitment to ask for > - if you don't have time to do that, you will get stale quickly - > you'll only see under >33% of the code changes going on (we're doing about 10 commits >a day - twice as many since december - and hopefully not slowing down!) > > Cheers, > Rob > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] Short vids showing current UI state
Hi, we made a couple of short videos for an internal 'show and tell what I'm currently working on' for colleagues - they show master tuskar/tuskar-ui/horizon as of ~Tuesday this week: Node Profile config @ https://www.youtube.com/watch?v=Ranfkx34dhg Shows definition of Node Profiles for each of compute, control and block-store. Assignment of these to the relevant Roles to prepare a deploy. - Nodes overview and deploy start @ https://www.youtube.com/watch?v=s2DAngZ8__E Shows overview of registered and available baremetal nodes (these are poseur in the vid) and then launch the deploy. Thought these may be interesting to anyone that hasn't seen/setup the UI recently, marios ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][reviews] We're falling behind
On 26/03/14 11:50, Ladislav Smola wrote: > On 03/25/2014 09:17 PM, Robert Collins wrote: >> TripleO has just seen an influx of new contributors. \o/. Flip side - >> we're now slipping on reviews /o\. >> >> In the meeting today we had basically two answers: more cores, and >> more work by cores. >> >> We're slipping by 2 reviews a day, which given 16 cores is a small >> amount. >> >> I'm going to propose some changes to core in the next couple of days - >> I need to go and re-read a bunch of reviews first - but, right now we >> don't have a hard lower bound on the number of reviews we request >> cores commit to (on average). >> >> We're seeing 39/day from the 16 cores - which isn't enough as we're >> falling behind. Thats 2.5 or so. So - I'd like to ask all cores to >> commit to doing 3 reviews a day, across all of tripleo (e.g. if your >> favourite stuff is all reviewed, find two new things to review even if >> outside comfort zone :)). >> >> And we always need more cores - so if you're not a core, this proposal >> implies that we'll be asking that you a) demonstrate you can sustain 3 >> reviews a day on average as part of stepping up, and b) be willing to >> commit to that. >> >> Obviously if we have enough cores we can lower the minimum commitment >> - so I don't think this figure should be fixed in stone. >> >> And now - time for a loose vote - who (who is a tripleo core today) >> supports / disagrees with this proposal - lets get some consensus >> here. >> >> I'm in favour, obviously :), though it is hard to put reviews ahead of >> direct itch scratching, its the only way to scale the project. >> >> -Rob >> > +1 > I'll do my best ditto > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Neutron error using devstack
On 12/03/14 08:34, abhishek jain wrote: > Thanks for the help. > I'm now able to proceed further with your suggestions. > I'm now enabling live migration in /etc/nova/nova.conf by adding the below > line > > live_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE > > > However now i need to restart nova-compute service, but whenever i try to > do the same,I'm getting the below logs > > sudo systemctl restart nova-compute.service > > Failed to issue method call: Unit nova-compute.service failed to load: No > such file or directory. See system logs and 'systemctl status > nova-compute.service' for details. > since you're running devstack you just use screen to stop and restart the n-cpu window (this is where nova-compute is running). There are plenty of resources out there about screen if you aren't familiar with it, but basically 'screen -rd' should get you started marios > Please help regarding this. > > > On Sun, Mar 2, 2014 at 12:42 AM, Elena Ezhova wrote: > >> If you want to use Neutron with devstack you have to add the related >> settings to localrc. >> >> Please see https://wiki.openstack.org/wiki/NeutronDevstack for detailed >> instructions. >> 01 марта 2014 г. 22:11 пользователь "abhishek jain" < >> ashujain9...@gmail.com> написал: >> >>> Hi all >>> >>> I have installed devstack successfully from the following link... >>> >>> >>> http://www.linux.com/learn/tutorials/721712-intro-to-openstack-part-two-how-to-install-and-configure-openstack-on-a-server >>> >>> However I'm not able to run the neutron services.The error which >>> generally comes after running neutron command is as follows. >>> >>> neutron subnet-create vxlan-net 10.100.1.0/24 --name vxlan-net >>> >>> You must provide a username via either --os-username or env[OS_USERNAME] >>> >>> ashu@ashu $ ps -ef | grep neutron >>> ashu31039 30660 0 18:09 pts/25 00:00:00 grep --color=auto neutron >>> >>> Please help regarding this >>> >>> ___ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][FYI] Bookmarklet for neutron gerrit review
On 04/03/14 23:00, Carl Baldwin wrote:
> Nachi,
>
> Great! I'd been meaning to do something like this. I took yours and
> tweaked it a bit to highlight failed Jenkins builds in red and grey
> other Jenkins messages. Human reviews are left in blue.
>
> javascript:(function(){
> list = document.querySelectorAll('td.GJEA35ODGC');
> for(i in list) {
> title = list[i];
> if(! title.innerHTML) { continue; }
> text = title.nextSibling;
> if (text.innerHTML.search('Build failed') > 0) {
> title.style.color='red'
> } else if(title.innerHTML.search('Jenkins|CI|Ryu|Testing|Mine') >= 0)
> {
> title.style.color='#66'
> } else {
> title.style.color='blue'
> }
> }
> })()
>
> Carl
>
> On Wed, Feb 26, 2014 at 12:31 PM, Nachi Ueno wrote:
>> Hi folks
>>
>> I wrote an bookmarklet for neutron gerrit review.
>> This bookmarklet make the comment title for 3rd party ci as gray.
>>
>> javascript:(function(){list =
>> document.querySelectorAll('td.GJEA35ODGC'); for(i in
>> list){if(!list[i].innerHTML){continue;};if(list[i].innerHTML &&
>> list[i].innerHTML.search('CI|Ryu|Testing|Mine') >
>> 0){list[i].style.color='#66'}else{list[i].style.color='red'}};})()
>>
>> enjoy :)
>> Nachi
thanks! for some weird reason I've never even tried bookmarklets before.
This is a great help for neutron reviews - its becoming really easy to
miss human comments between all the ci and test reports
marios
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron]A Question about creating instance with duplication sg_name
On 12/03/14 03:17, Xurong Yang wrote:
> Hi,Lingxian & marios
> Thank for response. yes,personally speaking, it should be using UUID
> instead of 'name' such as network_id port_id as name(not the key) can't
> differentiate security groups. so, i don't know that how about other
> folks's view, maybe we need fix it.
>
agreed. OK does the existing bug at
https://bugs.launchpad.net/neutron/+bug/1289195 cover you? If so let's
continue the discussion there (or create a new one)
thanks! marios
> thanks,Xurong
>
>
> 2014-03-11 21:33 GMT+08:00 mar...@redhat.com :
>
>> On 11/03/14 10:20, Xurong Yang wrote:
>>> It's allowed to create duplicate sg with the same name.
>>> so exception happens when creating instance with the duplicate sg name.
>>
>> Hi Xurong - fyi there is a review open which raises this particular
>> point at https://review.openstack.org/#/c/79270/2 (together with
>> associated bug).
>>
>> imo we shouldn't be using 'name' to distinguish security groups - that's
>> what the UUID is for,
>>
>> thanks, marios
>>
>>> code following:
>>>
>>> security_groups = kwargs.get('security_groups', [])
>>> security_group_ids = []
>>>
>>> # TODO(arosen) Should optimize more to do direct query for
>> security
>>> # group if len(security_groups) == 1
>>> if len(security_groups):
>>> search_opts = {'tenant_id': instance['project_id']}
>>> user_security_groups = neutron.list_security_groups(
>>> **search_opts).get('security_groups')
>>>
>>> for security_group in security_groups:
>>> name_match = None
>>> uuid_match = None
>>> for user_security_group in user_security_groups:
>>> if user_security_group['name'] == security_group:
>>> if name_match:---exception happened here
>>> raise exception.NoUniqueMatch(
>>> _("Multiple security groups found matching"
>>> " '%s'. Use an ID to be more specific.") %
>>>security_group)
>>>
>>> name_match = user_security_group['id']
>>>
>>>
>>> so it's maybe improper to create instance with the sg name parameter.
>>> appreciation if any response.
>>>
>>>
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron]A Question about creating instance with duplication sg_name
On 11/03/14 10:20, Xurong Yang wrote:
> It's allowed to create duplicate sg with the same name.
> so exception happens when creating instance with the duplicate sg name.
Hi Xurong - fyi there is a review open which raises this particular
point at https://review.openstack.org/#/c/79270/2 (together with
associated bug).
imo we shouldn't be using 'name' to distinguish security groups - that's
what the UUID is for,
thanks, marios
> code following:
>
> security_groups = kwargs.get('security_groups', [])
> security_group_ids = []
>
> # TODO(arosen) Should optimize more to do direct query for security
> # group if len(security_groups) == 1
> if len(security_groups):
> search_opts = {'tenant_id': instance['project_id']}
> user_security_groups = neutron.list_security_groups(
> **search_opts).get('security_groups')
>
> for security_group in security_groups:
> name_match = None
> uuid_match = None
> for user_security_group in user_security_groups:
> if user_security_group['name'] == security_group:
> if name_match:---exception happened here
> raise exception.NoUniqueMatch(
> _("Multiple security groups found matching"
> " '%s'. Use an ID to be more specific.") %
>security_group)
>
> name_match = user_security_group['id']
>
>
> so it's maybe improper to create instance with the sg name parameter.
> appreciation if any response.
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Editing Nodes
On 16/01/14 00:28, Clint Byrum wrote:
> Excerpts from James Slagle's message of 2014-01-15 05:07:08 -0800:
>> I'll start by laying out how I see editing or updating nodes working
>> in TripleO without Tuskar:
>>
>> To do my initial deployment:
>> 1. I build a set of images for my deployment for different roles. The
>> images are different based on their role, and only contain the needed
>> software components to accomplish the role they intend to be deployed.
>> 2. I load the images into glance
>> 3. I create the Heat template for my deployment, likely from
>> fragments that are already avaiable. Set quantities, indicate which
>> images (via image uuid) are for which resources in heat.
>> 4. heat stack-create with my template to do the deployment
>>
>> To update my deployment:
>> 1. If I need to edit a role (or create a new one), I create a new image.
>> 2. I load the new image(s) into glance
>> 3. I edit my Heat template, update any quantities, update any image uuids,
>> etc.
>> 4. heat stack-update my deployment
>>
>> In both cases above, I see the role of Tuskar being around steps 3 and 4.
>>
>
> Agreed!
>
+1 ...
review /#/c/52045/ is about generating the overcloud template using
merge.py **. Having recently picked this up again and following latest
wireframes and UI design, it seems like most of current Tuskar code is
going away. After initial panick I saw Jay has actually already started
that with /#/c/66062/
Jay: I think at some point (asap) my /#/c/52045/ will be rebased on your
/#/c/66062/. Currently my code creates templates from the Tuskar
representations, i.e. ResourceClasses. For now I will assume that I'll
be getting something along the lines of:
{
'resource_categories': { 'controller': 1, 'compute': 4, 'object': 1,
'block' 2}
}
i.e. just resource categories and number of instances for each (plus any
other user supplied config/auth info). Will there be controllers (do we
need them, apart from a way to create, update, delete)? Let's talk some
more on irc later. I'll update the commit message on my review to point
to yours for now,
thanks! marios
** merge.py is going to be binned but it is the best thing we've got
_today_ and within the Icehouse timeframe.
> Steps 1 and 2 are really CI's responsibility in a CD cloud. The end of
> the testing phase is "new images in glance!" For a stable release cloud,
> a tool for pulling new released images from elsewhere into Glance would
> be really useful, but worst case an admin downloads the new images and
> loads them manually.
>
>> I may be misinterpreting, but let me say that I don't think Tuskar
>> should be building images. There's been a fair amount of discussion
>> around a Nova native image building service [1][2]. I'm actually not
>> sure what the status/concensus on that is, but maybe longer term,
>> Tuskar might call an API to kick off an image build.
>>
>
> Tuskar should just deploy what it has available. I definitely could
> see value in having an image updating service separate from Tuskar,
> but I think there are many different answers for "how do images arrive
> in Glance?".
>
>> Ok, so given that frame of reference, I'll reply inline:
>>
>> On Mon, Jan 13, 2014 at 11:18 AM, Jay Dobies wrote:
>>> I'm pulling this particular discussion point out of the Wireframes thread so
>>> it doesn't get lost in the replies.
>>>
>>> = Background =
>>>
>>> It started with my first bulletpoint:
>>>
>>> - When a role is edited, if it has existing nodes deployed with the old
>>> version, are the automatically/immediately updated? If not, how do we
>>> reflect that there's a difference between how the role is currently
>>> configured and the nodes that were previously created from it?
>>
>> I would think Roles need to be versioned, and the deployed version
>> recorded as Heat metadata/attribute. When you make a change to a Role,
>> it's a new version. That way you could easily see what's been
>> deployed, and if there's a newer version of the Role to deploy.
>>
>
> Could Tuskar version the whole deployment, but only when you want to
> "make it so" ? If it gets too granular, it becomes pervasive to try and
> keep track of or to roll back. I think that would work well with a goal
> I've always hoped Tuskar would work toward which would be to mostly just
> maintain deployment as a Heat stack that nests the real stack with the
> parameters realized. With Glance growing Heat template storage capability,
> you could just store these versions in Glance.
>
>>> Replies:
>>
>> I know you quoted the below, but I'll reply here since we're in a new thread.
>>
>>> "I would expect any Role change to be applied immediately. If there is some
>>> change where I want to keep older nodes how they are set up and apply new
>>> settings only to new added nodes, I would create new Role then."
>>
>> -1 to applying immediately.
>>
>> When you edit a Role, it gets a new version. But nodes that are
>> deployed with the older version are not automatically upd
Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements
On 09/12/13 18:01, Jay Dobies wrote: >> I believe we are still 'fighting' here with two approaches and I believe >> we need both. We can't only provide a way 'give us resources we will do >> a magic'. Yes this is preferred way - especially for large deployments, >> but we also need a fallback so that user can say - no, this node doesn't >> belong to the class, I don't want it there - unassign. Or I need to have >> this node there - assign. > > +1 to this. I think there are still a significant amount of admins out > there that are really opposed to magic and want that fine-grained > control. Even if they don't use it that frequently, in my experience > they want to know it's there in the event they need it (and will often > dream up a case that they'll need it). +1 to the responses to the 'automagic' vs 'manual' discussion. The latter is in fact only really possible in small deployments. But that's not to say it is not a valid use case. Perhaps we need to split it altogether into two use cases. At least we should have a level of agreement here and register blueprints for both: for Icehouse the auto selection of which services go onto which nodes (i.e. allocation of services to nodes is entirely transparent). For post Icehouse allow manual allocation of services to nodes. This last bit may also coincide with any work being done in Ironic/Nova scheduler which will make this allocation prettier than the current force_nodes situation. > > I'm absolutely for pushing the magic approach as the preferred use. And > in large deployments that's where people are going to see the biggest > gain. The fine-grained approach can even be pushed off as a future > feature. But I wouldn't be surprised to see people asking for it and I'd > like to at least be able to say it's been talked about. > - As an infrastructure administrator, Anna wants to be able to view the history of nodes that have been in a deployment. >>> Why? This is super generic and could mean anything. >> I believe this has something to do with 'archived nodes'. But correct me >> if I am wrong. >> >> -- Jarda >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements
On 07/12/13 04:42, Tzu-Mainn Chen wrote: >> On 7 December 2013 08:15, Jay Dobies wrote: >>> Disclaimer: I'm very new to the project, so apologies if some of my >>> questions have been already answered or flat out don't make sense. >> >> >> NP :) >> >> * optional node profile for a resource class (M) * acts as filter for nodes that can be allocated to that class (M) >>> >>> >>> To my understanding, once this is in Icehouse, we'll have to support >>> upgrades. If this filtering is pushed off, could we get into a situation >>> where an allocation created in Icehouse would no longer be valid in >>> Icehouse+1 once these filters are in place? If so, we might want to make it >>> more of a priority to get them in place earlier and not eat the headache of >>> addressing these sorts of integrity issues later. >> >> We need to be wary of over-implementing now; a lot of the long term >> picture is moving Tuskar prototype features into proper homes like >> Heat and Nova; so the more we implement now the more we have to move. >> * Unallocated nodes >>> >>> >>> Is there more still being flushed out here? Things like: >>> * Listing unallocated nodes >>> * Unallocating a previously allocated node (does this make it a vanilla >>> resource or does it retain the resource type? is this the only way to >>> change >>> a node's resource type?) >> >> Nodes don't have resource types. Nodes are machines Ironic knows >> about, and thats all they are. > > Once nodes are assigned by nova scheduler, would it be accurate to say that > they > have an implicit resource type? Or am I missing the point entirely? > >>> * Unregistering nodes from Tuskar's inventory (I put this under >>> unallocated >>> under the assumption that the workflow will be an explicit unallocate >>> before >>> unregister; I'm not sure if this is the same as "archive" below). >> >> Tuskar shouldn't have an inventory of nodes. > > Would it be correct to say that Ironic has an inventory of nodes, and that we > may > want to remove a node from Ironic's inventory? right, in which case (needs to be clarified): Tuskar doesn't store info about nodes BUT Tuskar (??) the Tuskar UI (??) uses a client to fetch info directly from Ironic on demand (from the UI). ?? > > Mainn > >> -Rob >> >> >> -- >> Robert Collins >> Distinguished Technologist >> HP Converged Cloud >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO][Tuskar] Icehouse Requirements
On 06/12/13 04:31, Tzu-Mainn Chen wrote: > Hey all, > > I've attempted to spin out the requirements behind Jarda's excellent > wireframes > (http://lists.openstack.org/pipermail/openstack-dev/2013-December/020944.html). > Hopefully this can add some perspective on both the wireframes and the needed > changes to the tuskar-api. > > All comments are welcome! > > Thanks, > Tzu-Mainn Chen > > > > *** Requirements are assumed to be targeted for Icehouse, unless marked > otherwise: >(M) - Maybe Icehouse, dependency on other in-development features >(F) - Future requirement, after Icehouse > > * NODES >* Creation > * Manual registration > * hardware specs from Ironic based on mac address (M) > * IP auto populated from Neutron (F) > * Auto-discovery during undercloud install process (M) >* Monitoring >* assignment, availability, status >* capacity, historical statistics (M) >* Management node (where triple-o is installed) >* created as part of undercloud install process >* can create additional management nodes (F) > * Resource nodes > * searchable by status, name, cpu, memory, and all attributes from > ironic > * can be allocated as one of four node types > * compute > * controller > * object storage > * block storage > * Resource class - allows for further categorization of a node type > * each node type specifies a single default resource class > * allow multiple resource classes per node type (M) > * optional node profile for a resource class (M) > * acts as filter for nodes that can be allocated to that > class (M) > * nodes can be viewed by node types > * additional group by status, hardware specification > * controller node type >* each controller node will run all openstack services > * allow each node to run specified service (F) >* breakdown by workload (percentage of cpu used per node) (M) > * Unallocated nodes > * Archived nodes (F) > * Will be separate openstack service (F) > > * DEPLOYMENT >* multiple deployments allowed (F) > * initially just one >* deployment specifies a node distribution across node types > * node distribution can be updated after creation >* deployment configuration, used for initial creation only > * defaulted, with no option to change > * allow modification (F) >* review distribution map (F) >* notification when a deployment is ready to go or whenever something > changes > > * DEPLOYMENT ACTION >* Heat template generated on the fly > * hardcoded images > * allow image selection (F) > * pre-created template fragments for each node type > * node type distribution affects generated template sorry am a bit late to the discussion - fyi: there are two sides to these previous points 1) temp solution using merge.py from tuskar and the tripleo-heat-templates repo. (Icehouse, imo) and 2) doing it 'properly' with the merge functionality pushed into heat. (F, imo). For 1) various bits are in play: fyi/if interested: /#/c/56947/ (Make merge.py invokable), /#/c/58823/ (Make merge.py installable) and /#/c/52045/ (WIP : sketch of what using merge.py looks like for tuskar) this last one needs updating and thought. Also /#/c/58229/ and /#/c/57210/ which need some more thought, >* nova scheduler allocates nodes > * filters based on resource class and node profile information (M) >* Deployment action can create or update >* status indicator to determine overall state of deployment > * status indicator for nodes as well > * status includes 'time left' (F) > > * NETWORKS (F) > * IMAGES (F) > * LOGS (F) > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Stop logging non-exceptional conditions as ERROR
On 02/12/13 15:05, gustavo panizzo wrote: > On 11/27/2013 01:50 PM, Maru Newby wrote: >> Just a heads up, the console output for neutron gate jobs is about to get a >> lot noisier. Any log output that contains 'ERROR' is going to be dumped >> into the console output so that we can identify and eliminate unnecessary >> error logging. Once we've cleaned things up, the presence of unexpected >> (non-whitelisted) error output can be used to fail jobs, as per the >> following Tempest blueprint: >> >> https://blueprints.launchpad.net/tempest/+spec/fail-gate-on-log-errors >> >> I've filed a related Neutron blueprint for eliminating the unnecessary error >> logging: >> >> https://blueprints.launchpad.net/neutron/+spec/log-only-exceptional-conditions-as-error >> >> I'm looking for volunteers to help with this effort, please reply in this >> thread if you're willing to assist. > i want to help, i'm a newbie on openstack process, looking at > status.openstack.org i don't see any obvious place to start, could you > share a list of tests or a bug list? > hey gustavo, am in the same position as you: https://wiki.openstack.org/wiki/NeutronDevelopment and especially https://wiki.openstack.org/wiki/NeutronStarterBugs helped me, good luck! marios > thanks >> >> Thanks, >> >> >> Maru >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Reviews: tweaking priorities, and continual-deployment approvals
On 16/10/13 03:22, Robert Collins wrote: > Hi, during the TripleO meeting today we had two distinct discussions > about reviews. > > Firstly, our stats have been slipping: > http://russellbryant.net/openstack-stats/tripleo-openreviews.html > > > Stats since the last revision without -1 or -2 (ignoring jenkins): > > Average wait time: 2 days, 16 hours, 18 minutes > 1rd quartile wait time: 0 days, 11 hours, 1 minutes > Median wait time: 1 days, 9 hours, 37 minutes > 3rd quartile wait time: 5 days, 1 hours, 50 minutes > > > Longest waiting reviews (based on oldest rev without nack, ignoring jenkins): > > 7 days, 16 hours, 40 minutes https://review.openstack.org/50010 (Fix a > couple of default config values) > 7 days, 4 hours, 21 minutes https://review.openstack.org/50199 > (Utilizie pypi-mirror from tripleo-cd) > 6 days, 2 hours, 28 minutes https://review.openstack.org/50431 (Make > pypi-mirror more secure and robust) > 6 days, 1 hours, 36 minutes https://review.openstack.org/50750 (Remove > obsolete redhat-eventlet.patch) > 5 days, 1 hours, 50 minutes https://review.openstack.org/51032 > (Updated from global requirements) > > This is holding everyone up, so we want to fix it. When we discussed > it we found that there were two distinct issues: > A - not enough cross-project reviews > B - folk working on the kanban TripleO Continuous deployment stuff > had backed off on reviews - and they are among the most prolific > reviewers. > > A: Cross project reviews are super important: even if you are only > really interested in (say) os-*-config, it's hard to think about > things in context unless you're also up to date with changing code > (and the design of code) in the rest of TripleO. *It doesn't matter* > if you aren't confident enough to do a +2 - the only way you get that > confidence is by reviewing and reading code so you can come up to > speed, and the only way we increase our team bandwidth is through folk > doing that in a consistent fashion. > > So please, whether your focus is Python APIs, UI, or system plumbing > in the heart of diskiamge-builder, please take the time to review > systematically across all the projects: > https://wiki.openstack.org/wiki/TripleO#Review_team > > B: While the progress we're making on delivering a production cloud is > hugely cool, we need to keep our other responsibilities in check - > https://wiki.openstack.org/wiki/TripleO#Team_responsibilities - is a > new section I've added based on the meeting. Even folk working on the > pointy end of the continuous delivery story need to keep pulling on > the common responsibilities. We said in the meeting that we might > triage it as follows: > - review reviews for firedrills first. (Critical bugs, things > breaking the CD cloud) > - review reviews for the CD cloud > - then all reviews for the program > with a goal of driving them all to 0: if we're on top of things, that > should never be a burden. If we run out of time, we'll have unblocked > critical things first, unblocked folk working on the pointy edge > second - bottlenecks are important to unblock. We'll review how this > looks next week. > I can at least promise :) to become a more useful member of the team over time; to be honest there's a lot of _new_ going on very quickly and even the workflow is new to me (gerrit, bluprints, bugs, etc). The discussion about triage on yesterday's call (and your email) definitely makes it a more immediately accessible task for me to look at and the clarification around +1/-1 also helps, thanks, marios > # The second thing > > The second issue was raised during the retrospective (which will be up > at https://wiki.openstack.org/wiki/TripleO/TripleOCloud/MVP1and2Retrospective > a little later today. With a production environment, we want to ensure > that only released code is running on it - running something from a > pending review is something to avoid. But, the only way we've been > able to effectively pull things together has been to run ahead of > reviews :(. A big chunk of that is due to a lack of active +2 > reviewers collaborating with the CD cloud folk - we would get a -core > putting a patch up, and a +2, but no second +2. We decided in the > retrospective to try permitting -core to +2 their own patch if it's > straightforward and part of the current CD story [or a firedrill]. We > set an explicit 'but be sure you tested this first' criteria on that : > so folk might try it locally, or even monkey patch it onto the cloud > for one run to check it really works [until we have gating on the CD > story/ies]. > > Cheers, > Rob > > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Tuskar] Resource Classes and Racks (Wireframes + Concept Discussion)
On 01/10/13 00:07, Jaromir Coufal wrote: > Just BTW: > > I know that lot of folks were watching the youtube stream > (http://youtu.be/m3y6uD8yKVQ), so please feel free to give any feedback > you have to this thread. I believe that this is good way to proceed > forward and how to make things flexible enough to support various types > of deployments. > > Looking forward to any feedback my 2c: * I like LGroup. You can still create an LGroup where all nodes in a physical rack are in the same LGroup (i.e. what we have now in Rack). However, it also means you can divide a given physical rack of servers into two or more LGroups (eg TOR switch setup to give you two rack-local subnets). Gives much better capacity planning. For Tuskar... currently a 'Rack' is just a list of node_ids ... so the concept should actually map fine - I think? * hardware profile on a resource class... nice idea... i like the auto matching of profiles to particular nodes though obviously thats a while away yet. In tuskar we'd need to expand the resource class definition and operations for capturing the hardware profiles. Right now only racks have this notion of 'aggregate capacity' and resource class doesn't expose the total aggregate 'total resource capacity' or aggregate 'total instance capacity'. marios > > Thanks > -- Jarda > > On 2013/30/09 13:57, Jaromir Coufal wrote: >> Hi everyone, >> >> based on Tuskar's merger with TripleO and upstream feedback on Tuskar, >> when I was thinking about processes and workflows there, I got into >> some changes which I think that are important for us, because they >> will help us to achieve better flexibility and still having ability >> for easy scaling. >> >> I wanted to do just walkthrough the wireframes but I think that it >> will raise up some discussion around Classes and Racks, so my thought >> was to merge both together (wireframes + concepts discussion). >> >> At this meeting I'd like to get you familiar with my thoughts and get >> into some wireframes which will explain the ideas more. I hope that we >> will get into discussion around changes (not just UI but API as well). >> >> The scope which we will be talking about is Icehouse. >> >> I'll be posting link into #tripleo IRC channel. >> I'd like to record the whole session, so if anybody cannot attend, it >> should be available for you later. >> >> (Please note that Google Hangout has limited number of 10 >> participants, so if you consider just watching, please use youtube >> stream - link will be posted here when available.) >> >> Thanks >> -- Jarda >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Tuskar and releases
On 02/10/13 12:52, Thierry Carrez wrote: > Monty Taylor wrote: >> >> >> On 10/01/2013 08:08 PM, Robert Collins wrote: >>> We'd like to get tuskar projects doing releases sooner rather than >>> later. For python-tuskarclient, this is pretty much a no-brainer : we >>> just need to start doing it. +1000, but imo there is a release blocker that must be addressed first for any kind of release. Tuskar api depends on an under review patch by Martyn @ https://review.openstack.org/#/c/48453/ (no -1 yet). Without it we don't have a way of saying put _this_ image onto _this_ baremetal node, thanks, marios >> >> Yup. Just do it. >> >>> However, for tuskar-ui and tuskar it's more complex. >>> >>> # tuskar >>> >>> This is an API service; whats the story for non-integrated projects >>> and releases? Can we do them, or does the release team do them? Does >>> it make integration/incubation any harder? >> >> Thus far, non-integrated project can pretty much release however they >> want to. Things that would like to get integrated tend to start >> following release process and timelines on their own, but nothing >> requires it until such a time as the release team takes it over. > > Agreed. Actually making releases before applying for incubation is a > good idea. The only thing to watch is to avoid numbering your releases > above the openstack numbering (.i) so that when you get integrated > you don't need epoch tricks. Using 0.x, 1.x etc. is usually working well. > > Cheers, > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tuskar] pecan models vs. db models
On 23/09/13 21:59, Doug Hellmann wrote: > On Mon, Sep 23, 2013 at 12:31 PM, Petr Blaho wrote: > >> Hi, >> >> during my work on getting tests to pass for >> https://review.openstack.org/#/c/46947/ I discovered that we are >> misusing pecan models for HTTP representation of Resources. >> >> In controllers pecan/wsme calls actions with pecan model prepopulated >> from HTTP request's params. >> >> For example, when creating new Rack, post >> method in Racks controller is called with rack object >> ( >> https://github.com/stackforge/tuskar/blob/master/tuskar/api/controllers/v1/rack.py#L26-L31). >> This object is instance of Rack from >> >> https://github.com/stackforge/tuskar/blob/master/tuskar/api/controllers/v1/types/rack.py >> . >> Next this object is used in pecan.request.dbapi.create_rack(rack) call >> (method defined here >> >> https://github.com/stackforge/tuskar/blob/master/tuskar/db/sqlalchemy/api.py#L385-L431 >> ) >> >> This method just assumes that new_rack object (passed from controller) >> has some attributes with getters defined (name, subnet, location, ...). >> >> This is fine if we have 1-1 relationship between how resource is stored >> in db and how it is represented via HTTP. In fact this assumes that both >> versions have the same set of atributes. >> >> Marios wrote a patch (mentioned above) which needs some internal >> attributes only, ie. present in table but not exposed via HTTP. >> >> In that moment I found that we use pecan models ( >> >> https://github.com/stackforge/tuskar/tree/master/tuskar/api/controllers/v1/types) >> to transfer HTTP params _directly_ to our db layer >> ( >> https://github.com/stackforge/tuskar/blob/master/tuskar/db/sqlalchemy/api.py). >> By _directly_ I mean that we assume 1-1 mapping between attributes in >> pecan models and db models. >> >> This is not to be true anymore. We can solve it by using conditionals like >> this >> https://review.openstack.org/#/c/46947/3/tuskar/db/sqlalchemy/api.py >> (lines 175 to 181) but I think this is not good solution b/c of repetion >> of code and generaly we are mixing up HTTP repr. with db repr. >> >> I propose to write a simple layer responsible for "translating" pecan >> models into db representation. This way we can keep all diffs in what >> attributes are exposed via HTTP and which not in one place - easy to >> see, easy to change, easy to review. To scatter it around dbapi code >> is not a good way IMHO. Hey Petr: I believe you mentioned 'service models' yesterday :) on irc - well we also used these in Deltacloud for the CIMI frontend - the API calls out to the service models which handle talking to the database and instantiating the separate object models. If understood correctly this is also what Doug is proposing. I think it's a great idea. My personal concern is getting the HK stories done without too much disruption and this would be a major change. Though I also understand that precisely for this reason we should do it sooner rather than later. Do you think this is something you can work on in parallel to current dev, rebasing as frequently as possible from master and aim to merge immediately after HK? This is my vote anyway - thoughts? You could even keep a gerrit review going and update that to encourage more people to look thanks, marios > > >> >> Another issue which comes with this coupling of pecan/db models is in >> tests. >> >> In db tests we use utility helpers for creating resources in memory, ie >> create_test_resource_class method ( >> >> https://github.com/stackforge/tuskar/blob/master/tuskar/tests/db/test_db_racks.py#L28 >> ). This kind of methods comes from "from tuskar.tests.db import utils" >> and they use pecan models ( >> >> https://github.com/stackforge/tuskar/blob/master/tuskar/tests/db/utils.py#L17-L23). >> We are now on the same page as mentioned above. These db tests uses >> Relation and Link pecan models which means that easy solution like >> importing db models instead of pecan models is not doable at the moment >> b/c db models do not contains direct counterparts for Relation and Link. >> >> >> I am pretty woried about this pecan-db models coupling b/c if (or when) >> we will need more different stuctures on HTTP side than on db side (no >> 1-1 relationship) we will have to change our code and tests more. >> >> I hope that we will find a solution for this sooner than tuskar code >> will grow more complex. >> >> >> I would like to see something like "service objects" in controller part >> but simple set of "translations" can be ok if we do not break 1-1 parity >> too >> much. >> > > Yes, you definitely do not want to be using WSME models in the storage > layer. In addition to the issues you've already discovered with the > database schema not mapping directly to the API schema, it will force the > storage code to depend on web front-end code. > > In ceilometer, we solved this problem by creating a separate set of models > for the storage layer: > https://github.com/openstack
Re: [openstack-dev] [Tuskar] AI "How does tuskar fit in with TripleO"
On 18/09/13 19:44, Robert Collins wrote: > On 18 September 2013 20:59, mar...@redhat.com wrote: >> I have an AI from the tuskar community meeting to come up with a >> description of how TripleO 'differs from' Tuskar. I have no idea where >> this will be used/placed and in fact I don't know where to send it: >> should we paste it into the naming etherpad, open a launchpad docs >> blueprint (seems a bit much, especially as I don't know which doc it's >> going into). Alternatively please feel free to change and use as you see >> fit wherever: >> >> >> " >> >> How does tuskar fit in with TripleO? >> >> >> TripleO [1] is a blanket term for a number of subprojects - but the > > Huh? TripleO is the OpenStack Deployment project codename: we're a > program focused on production deployment of OpenStack at scale. The > fact we have a number of specific projects to facilitate that is just > good engineering, exactly the same as nova having the server API and > client in different projects. indeed ^^^ and this is how I intended it - the same way that 'nova' is a collection of related but distinct services (compute, scheduler, api, message bus/broker, etc) - tbh that's the first time I've seen 'OpenStack Deployment project' so my apologies for not using that > > What you've written below is correct, but it's implementation detail :) > > >> Tuskar [2] is actually a perfect fit for TripleO and entirely depends on >> the TripleO concept and services to do all of the heavy lifting. >> Actually, Tuskar may in part be defined as a *design* tool. With Tuskar, >> you get a UI and API with which you can tell the undercloud >> nova-baremetal service exactly which OpenStack services (i.e. baremetal >> images) to deploy onto which machines in the datacenter. The UI >> integrates into the default OpenStack Horizon dashboard and allows you >> to define your datacenter in terms of Racks (groups of physical machines >> registered by id/mac_address) and ResourceClasses (groups of Racks that >> all provide the same Overcloud service 'compute' vs 'block_storage'). >> >> >> In the simplest terms, Tuskar translates your definition into the >> undercloud machine HEAT template, allowing you to then provision your >> datacenter at the push of a button. Beyond this planning/design, Tuskar >> also monitors the datacenter, allowing operators to make most efficient >> use of capacity. Ultimately, Tuskar aims to allow you to plan, define, >> deploy and monitor your datacenter in an accessible, scalable, >> repeatable, highly available and secure way. >> " > > FWIW I see keeping the deployed OpenStack up to date, performing well, > scaling it up and down, replacing hardware etc as all part of the > production deployment problem : we'd be delighted to have those > facilities be part of the TripleO program - but we have to walk before > we run :). > I just read Tomas e-mail, this is great news :) marios > Cheers, > Rob > > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Tuskar] [TripleO] The vision and looking ahead
On 19/09/13 11:08, Tomas Sedovic wrote: > Hi everyone, > > Some of us Tuskar developers have had the chance to meet the TripleO > developers face to face and discuss the visions and goals of our projects. > > Tuskar's ultimate goal is to have to a full OpenStack management > solution: letting the cloud operators try OpenStack, install it, keep it > running throughout the entire lifecycle (including bringing in new > hardware, burning it in, decommissioning), help to scale it, secure the > setup, monitor for failures, project the need for growth and so on. > > And to provide a good user interface and API to let the operators > control and script this easily. > > Now, the scope of the OpenStack Deployment program (TripleO) includes > not just installation, but the entire lifecycle management (from racking > it up to decommissioning). Among other things they're thinking of are > issue tracker integration and inventory management, but these could > potentially be split into a separate program. > > That means we do have a lot of goals in common and we've just been going > at them from different angles: TripleO building the fundamental > infrastructure while Tuskar focusing more on the end user experience. > > We've come to a conclusion that it would be a great opportunity for both > teams to join forces and build this thing together. > > The benefits for Tuskar would be huge: > > * being a part of an incubated project > * more eyballs (see Linus' Law (the ESR one)) > * better information flow between the current Tuskar and TripleO teams > * better chance at attracting early users and feedback > * chance to integrate earlier into an OpenStack release (we could make > it into the *I* one) > > TripleO would get a UI and more developers trying it out and helping > with setup and integration. > > This shouldn't even need to derail us much from the rough roadmap we > planned to follow in the upcoming months: > > 1. get things stable and robust enough to demo in Hong Kong on real > hardware > 2. include metrics and monitoring > 3. security > > What do you think? > this is fantastic news ! marios > Tomas > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Tuskar] AI "How does tuskar fit in with TripleO"
I have an AI from the tuskar community meeting to come up with a description of how TripleO 'differs from' Tuskar. I have no idea where this will be used/placed and in fact I don't know where to send it: should we paste it into the naming etherpad, open a launchpad docs blueprint (seems a bit much, especially as I don't know which doc it's going into). Alternatively please feel free to change and use as you see fit wherever: " How does tuskar fit in with TripleO? TripleO [1] is a blanket term for a number of subprojects - but the basic jist of it is you start with a controller 'undercloud' machine, meaning it is an OpenStack setup where the nova-compute service is using the baremetal driver rather than any other hypervisor specific driver. The TripleO concept is to use this baremetal nova-compute service, together with HEAT (also on this 'undercloud' machine/available to it) and diskimage-builder/TOCI to deploy OpenStack, with OpenStack. In other words, with Triple-O you can use the OpenStack API itself to instuct your undercloud nova-compute service to deploy entire OpenStack service(s) (compute service, block storage etc) which become your end-user "overcloud(s)" ( ;) ). This is frickin' awesome. Tuskar [2] is actually a perfect fit for TripleO and entirely depends on the TripleO concept and services to do all of the heavy lifting. Actually, Tuskar may in part be defined as a *design* tool. With Tuskar, you get a UI and API with which you can tell the undercloud nova-baremetal service exactly which OpenStack services (i.e. baremetal images) to deploy onto which machines in the datacenter. The UI integrates into the default OpenStack Horizon dashboard and allows you to define your datacenter in terms of Racks (groups of physical machines registered by id/mac_address) and ResourceClasses (groups of Racks that all provide the same Overcloud service 'compute' vs 'block_storage'). In the simplest terms, Tuskar translates your definition into the undercloud machine HEAT template, allowing you to then provision your datacenter at the push of a button. Beyond this planning/design, Tuskar also monitors the datacenter, allowing operators to make most efficient use of capacity. Ultimately, Tuskar aims to allow you to plan, define, deploy and monitor your datacenter in an accessible, scalable, repeatable, highly available and secure way. " thanks, marios [1] http://www.openstack.org/summit/portland-2013/session-videos/presentation/openstack-on-openstack-overview [2] https://www.youtube.com/watch?feature=player_embedded&v=VEY035-Lyzo ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
