Re: [openstack-dev] [third-party] Zuul trigger not starting Jenkins jobs
On 7/20/14, 5:25 PM, daya kamath wrote: all, Need some pointers on debugging what the issue is. its not very convenient for me to be on the IRC due to timezone issues, so hoping the mailing list is a good next best option.. when i post a patch on the sandbox project, i see a review indicating my system is starting 'check' jobs, but i dont see any activity in Jenkins for the job. i can run the job manually from the master. tia! daya - output from review.openstack.org - IBM Neutron Testing Jul 14 3:33 PM Patch Set 1: Starting check jobs. http://127.0.0.1/zuul/status output log from Zuul debug- Paste #86642 | LodgeIt!http://paste.openstack.org/show/86642/ Paste #86642 | LodgeIt!http://paste.openstack.org/show/86642/ debug log - 2014-07-16 07:57:57,077 INFO zuul.Gerrit: Updating information for 106722,1 2014-07-16 07:57:57,936 DEBUG zuul.Gerrit: Change Change 0x7f0f4e5d64d0 106722,1 status: NEW 2014-07-16 07:57:57,936 DEBUG zuul.Scheduler: Adding trigger event: TriggerEvent... View on paste.openstack.orghttp://paste.openstack.org/show/86642/ Preview by Yahoo (configuration shows the job mapping properly, and its receiving the triggers from the upstram, but these are not firing any Jenkins jobs) The Jenkins master connection to Gearman is showing status as ok. gearman status command output - status build:noop-check-communication:master 0 0 2 build:dsvm-tempest-full 0 0 2 build:dsvm-tempest-full:devstack_slave 0 0 2 merger:merge0 0 1 build:ibm-dsvm-tempest-full 0 0 2 zuul:get_running_jobs 0 0 1 set_description:9.126.153.171 0 0 1 build:ibm-dsvm-tempest-full:devstack_slave 0 0 2 stop:9.126.153.171 0 0 1 zuul:promote0 0 1 build:noop-check-communication 0 0 2 zuul:enqueue0 0 1 merger:update 0 0 1 Hi Daya, I did ping you back in IRC last week; however you, unfortunately had already signed off. I have tried to ping you several times since, but every time I have checked you have not been online. In my experience, this issue has been caused by a mismatch in the jobs configured in the Zuul pipelines and those configured in Jenkins. Can you post your Jenkins jobs builder files (your projects.yaml file and the yaml file which you defined the ibm-dsvm-dempest-full job in? Also, please post your zuul.conf file and your layout.yaml files as well. Please feel free to follow up with me at swes...@brocade.commailto:swes...@brocade.com. I will be happy to continue our discussion over email. Thanks, Steve Weston OpenStack Software Engineer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [third-party] Zuul trigger not starting Jenkins jobs
On 7/21/14, 3:13 AM, daya kamath wrote:
hi steve,
thanks a lot for following up! i'm based out of india, so there's not much
overlap in timezones. i'll unicast you for next steps. wanted to post the info
you asked for in this thread.
the 2 files are here - Paste #87382 |
LodgeIt!http://paste.openstack.org/show/87382/
Paste #87382 | LodgeIt!http://paste.openstack.org/show/87382/
examples.yaml - -
job-template: name: 'noop-check-communication' node: '{node}' builders: -
shell: | #!/bin/bash -xe echo Hello world, this is the {vendor} Testing
System - job-tem...
View on paste.openstack.orghttp://paste.openstack.org/show/87382/
Preview by Yahoo
i just have some customizations to devstack-gate script, but the overall
framework more or less intact as cloned from
https://raw.github.com/jaypipes/os-ext-testing/master/puppet/install_master.sh.
not using nodepools currently, just 1 master and 1 slave node.
thanks!
From: Steven Weston swes...@brocade.commailto:swes...@brocade.com
To: daya kamath day...@yahoo.commailto:day...@yahoo.com; OpenStack
Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Sent: Monday, July 21, 2014 1:53 PM
Subject: Re: [openstack-dev] [third-party] Zuul trigger not starting Jenkins
jobs
On 7/20/14, 5:25 PM, daya kamath wrote:
all,
Need some pointers on debugging what the issue is. its not very convenient for
me to be on the IRC due to timezone issues, so hoping the mailing list is a
good next best option..
when i post a patch on the sandbox project, i see a review indicating my system
is starting 'check' jobs, but i dont see any activity in Jenkins for the job. i
can run the job manually from the master.
tia!
daya
-
output from review.openstack.org -
IBM Neutron Testing
Jul 14 3:33 PM
Patch Set 1:
Starting check jobs. http://127.0.0.1/zuul/status
output log from Zuul debug-
Paste #86642 | LodgeIt!http://paste.openstack.org/show/86642/
Paste #86642 | LodgeIt!http://paste.openstack.org/show/86642/
debug log - 2014-07-16 07:57:57,077 INFO zuul.Gerrit: Updating information for
106722,1 2014-07-16 07:57:57,936 DEBUG zuul.Gerrit: Change Change
0x7f0f4e5d64d0 106722,1 status: NEW 2014-07-16 07:57:57,936 DEBUG
zuul.Scheduler: Adding trigger event: TriggerEvent...
View on paste.openstack.orghttp://paste.openstack.org/show/86642/
Preview by Yahoo
(configuration shows the job mapping properly, and its receiving the triggers
from the upstram, but these are not firing any Jenkins jobs)
The Jenkins master connection to Gearman is showing status as ok.
gearman status command output -
status
build:noop-check-communication:master 0 0 2
build:dsvm-tempest-full 0 0 2
build:dsvm-tempest-full:devstack_slave 0 0 2
merger:merge0 0 1
build:ibm-dsvm-tempest-full 0 0 2
zuul:get_running_jobs 0 0 1
set_description:9.126.153.171 0 0 1
build:ibm-dsvm-tempest-full:devstack_slave 0 0 2
stop:9.126.153.171 0 0 1
zuul:promote0 0 1
build:noop-check-communication 0 0 2
zuul:enqueue0 0 1
merger:update 0 0 1
Hi Daya,
I did ping you back in IRC last week; however you, unfortunately had already
signed off. I have tried to ping you several times since, but every time I
have checked you have not been online.
In my experience, this issue has been caused by a mismatch in the jobs
configured in the Zuul pipelines and those configured in Jenkins. Can you post
your Jenkins jobs builder files (your projects.yaml file and the yaml file
which you defined the ibm-dsvm-dempest-full job in? Also, please post your
zuul.conf file and your layout.yaml files as well.
Please feel free to follow up with me at
swes...@brocade.commailto:swes...@brocade.com. I will be happy to continue
our discussion over email.
Thanks,
Steve Weston
OpenStack Software Engineer
Daya,
Everything looks correct to me. Curious, however, that you only have one slave
and you have two workers registered in the gearman server. If you connect to
the gearman server and execute the workers command, what do you get as output?
I might suggest, at this point, the following:
1. Disable your gearman-jenkins plugin.
2. Shut down your Jenkins service.
3. On your Jenkins master, cd into /var/lib/jenkins/plugins and rm -rf
gearman-plugin*
4. Start the Jenkins service, verify the plugin is removed, then shut it back
down.
5. cd /var/lib/jenkins/plugins wget
http://tarballs.openstack.org/ci/gearman-plugin.hp
6. Start the Jenkins service again.
7. Make sure you reconnect to the Gearman server.
This has resolved many issues I've had in getting Jenkins to talk to Gearmand.
Steve
Re: [openstack-dev] [Neutron] Blueprint -- Floating IP Auto Association
Hi Salvatore! My responses (to your responses) are in-line. I think we could also use some feedback from the rest of the community on this, as well ... would it be a good idea to discuss the implementation further at the next IRC meeting? Good Stuff!! Steven On 11/15/2013 7:39 AM, Salvatore Orlando wrote: On 14 November 2013 23:03, Steven Weston steven-wes...@live.com mailto:steven-wes...@live.com wrote: Hi Salvatore, My Launchpad ID is steven-weston. I do not know who those other Steven Westons are ... if someone has created clones of me, I am going to be upset! Anyway, Here are my thoughts on the implementation approach. I have now assigned the blueprint to you. Great, thank you! Is there any reason why the two alternatives you listed should be considered mutually exclusive? In line of principle they're not. But if we provide the facility in Neutron, doing the orchestration from nova for the association would be, in my opinion, just redundant. Unless I am not understanding what you suggest. I agree, implementing the functionality in nova and neutron would be redundant, although I was suggesting that the nova api be modified to allow for the auto association request on vm creation, which would then be passed to neutron for the port creation. Currently it looks to only be available as a configuration option in nova. So far I understand the goal is to pass a 'autoassociate_fip' flag (or something similar) to POST /v2/port the operation will create two resource: a floating IP and a port, with only the port being returned (hence the side-effect). This sounds good, unless we want to modify the api behavior to return a list of floating ips, as you already suggested below. Or would it be better to return a mapping of fixed ips to floating ips, since that would technically be more accurate? I think that in consideration of loosely coupled design, it would be best to make the attribute addition to the port in neutron and create the ability for nova to orchestrate the call as well. I do not see a way to prevent modification of the REST API, and in the interest of fulfilling your concern of atomicity, the fact that an auto association was requested will need to be stored somewhere, in addition to the state of the request as well. Storing the autoassociation could be achieved with a flag on the floating IP data model. But would that also imply that the association for an auto-associate floatingIP cannot be altered? I think that depends on how we want it to work ... see my comments below. Plus, tracking the attribute in neutron would allow the ability of other events to fire that would need to be performed in response to an auto associate request, such as split zone dns updates (for example). The primary use case for this would be for request by nova, although I can think of other services which could use it as well -- load balancers, firewalls, vpn's, and any component that would require connectivity to another network. I think the default behavior of the auto association request would be to create ip addresses on the associated networks of the attached routers, unless a specific network is given. Perhaps I need more info on this specific point; I think the current floating_port_id - port_id might work to this aim; perhaps the reverse mapping would be needed to, and we might work to add id - but I don't see why we would need a 'auto_associate' flag. This is not a criticism. It's just me being dumb perhaps! This one is my fault, I should have been more clear as to what I was thinking ... the purpose of the flag would be to provide some sort of state that a floating ip was allocated as the result of an auto-association .. not necessarily for consumption by neutron, but for other services that might want to use the information. I do see a reason to store it for Neutron's usage as well, but I guess that would depend on whether the behavior of an auto associated floating ip address would be different than a normal, independently associated floating ip address. Which brings up a few good implementation questions. 1. Should the mapping between the floating and fixed be immutable? 2. When the port is deleted, should the floating ip address be removed as well? 3. What about in the reverse situation, should deletion of the floating ip address be denied until the port no longer exists? Depending on what your answers are to these questions, then IMHO I would suggest possibly adding an is_auto_associated flag to the floating ip data model, as you alluded to above. I apologize if these situations are already addressed in Neutron ... if they are, I couldn't find them ... I believe they are currently handled by nova. If I am incorrect on this, please point me in the right direction! To conclude I think it might be actually not bad at all
Re: [openstack-dev] [Neutron] Blueprint -- Floating IP Auto Association
Hi Salvatore, My Launchpad ID is steven-weston. I do not know who those other Steven Westons are … if someone has created clones of me, I am going to be upset! Anyway, Here are my thoughts on the implementation approach. Is there any reason why the two alternatives you listed should be considered mutually exclusive? I think that in consideration of loosely coupled design, it would be best to make the attribute addition to the port in neutron and create the ability for nova to orchestrate the call as well. I do not see a way to prevent modification of the REST API, and in the interest of fulfilling your concern of atomicity, the fact that an auto association was requested will need to be stored somewhere, in addition to the state of the request as well. Plus, tracking the attribute in neutron would allow the ability of other events to fire that would need to be performed in response to an auto associate request, such as split zone dns updates (for example). The primary use case for this would be for request by nova, although I can think of other services which could use it as well -- load balancers, firewalls, vpn’s, and any component that would require connectivity to another network. I think the default behavior of the auto association request would be to create ip addresses on the associated networks of the attached routers, unless a specific network is given. Thoughts? Ideas? Criticisms? Complements? :) Steven Original message From: Salvatore Orlando sorla...@nicira.com mailto:sorla...@nicira.com Date: 11/14/2013 4:23 AM (GMT-07:00) To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Blueprint -- Floating IP Auto Association Hi Steven, I see three Steven Weston on Launchpad. If you give me your LP ID, I will assign the blueprint to you. This is a nova parity item and i'd like to raise the priority to High. It would be also good to hear from you about the implementation approach. In the past we debated two alternatives: passing a special attribute to a port in order to create a floating IP for it too, or orchestrating the operation from the nova side. The first option has the cons of adding a side effect to a REST API call (which is not advisable), and might be a bit complex when the network where the port is on is attached to multiple routers. The latter option has the cons of requiring two neutron API calls. The input of the whole community on this topic will be very appreciated. Salvatore On 14 November 2013 05:47, Steven Weston steven-wes...@live.com mailto:steven-wes...@live.com wrote: Thanks for the responses on this. I definitely still interested in implementing the functionality described in this blueprint, but have been reluctant to start on it since I did not get a response. Yes, please assign it to me and I will get started on it right away! I do not seem to have the capability to assign it to myself. Steven From: Jaume Devesa [mailto:devv...@gmail.com mailto:devv...@gmail.com ] Sent: Wednesday, November 13, 2013 10:32 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] Blueprint -- Floating IP Auto Association Hi all, I see it has been passed two weeks since first mail in this thread and that blueprint still without assignee. I also think this is a good option for my first blueprint. However, I can not assign blueprints to myself, only bugs. Can anybody assign to me? Steven: if you still interested in it, please tell us. You asked for it first and it will be yours. Regards On 5 November 2013 07:21, Salvatore Orlando sorla...@nicira.com mailto:sorla...@nicira.com wrote: I don't think there has been any development in the past 6 months. A few people have shown interest in it in the past, but the blueprint has currently no assignee. So If you want to work on it, feel free to assign to yourself. To quickly sum up the discussion around this blueprint, it could be implemented in two ways: - providing automation in the neutron API (creating the floating IP together with the port) - automating the operation on the orchestration side (nova-api in this case). There are pro and cons in both solutions. In my humble opinion, the only thing I would care of is that the existing operation in the Neutron API stay atomic as they are. Regards, Salvatore On 30 October 2013 08:46, Steven Weston steven-wes...@live.com mailto:steven-wes...@live.com wrote: Does anybody know what the status of this Blueprint is? https://blueprints.launchpad.net/neutron/+spec/auto-associate-floating-ip I am new to the neutron developer community and I am looking for a first project – this might be a good place to start. But the last update was in March of this year, so I don’t know
[openstack-dev] [Neutron] Blueprint -- Floating IP Auto Association
Does anybody know what the status of this Blueprint is? https://blueprints.launchpad.net/neutron/+spec/auto-associate-floating-ip I am new to the neutron developer community and I am looking for a first project - this might be a good place to start. But the last update was in March of this year, so I don't know if the specifications have been locked down yet. Anybody? Thanks! Steven Weston ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
